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Briefly  stated  *jthe  goals  of  the  AIS  plan  are  to  introduce 
in  the  operational  systems  of  the  Bureau  the  following 
modern  data  processing  technologies: 

-  Integrated  database  management^, 

-  Structured  programming^ 

Development  environments  that  improve  the 
portability  of  system  software^  a  ,  ^ 

-  Virtual  machines  and  data  abstraction  techniques 
in  support  of  architectural  design. 

Concurrent  with  the  introduction  of  these  software 
technologies. AIS  is  aimed  at  greatly  expanding  the  access 
to  computer  resources  by  the  clerical  staffs  of  the  Bureau. 

The  ultimate  significance  of  the  AIS  development  rests  on 
accelerating  and  streamling  a  number  of  personnel  assignment 
(distribution) ,  training,  selection,  etc.  functions  as 
well  as  providing  better  support  of  manpower  and  planning 
activities . 

GSG's  activities  during  the  contract  period  consisted  in 
a  number  of  reviews.  Each  review  considered  research, 
architectural  design,  software  engineering,  development 
management  and  procurement  issues. 

The  first  review  is  concerned  with  a  very  interesting 
,  applied  research  program  underway  at  Randolph  AFB  by  the 
Military  Personnel  Center  (MPC)  of  the  Air  Force. 

The  second  major  review  is  an  in-depth  program  review  of 
the  entire  AIS  program  at  Bupers. 
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1.0  Introduction 

In  this  final  report  for  Contract  No.  N00014-76-C-1104  we 
will  document  the  major  technical  activities  of  the  program. 

The  objective  of  the  program  was  to  assist  the  Bureau  of 
Naval  Personnel  in  their  development  of  the  Advanced 
Information  System  (AIS) . 

Briefly  stated  the  goals  of  the  AIS  plan  are  to  introduce 
in  the  operational  systems  of  the  Bureau  the  following 
modern  data  processing  technolocies : 

Integrated  database  management 

-  Structured  programming 

-  Development  environments  that  improve  the 
portability  of  system  software 

Virtual  machines  and  data  abstraction  techniques 
in  support  of  architectural  design 

Concurrent  with  the  introduction  of  these  software  technologies 
AIS  is  aimed  at  greatly  expanding  the  access  to  computer 
resources  by  the  clerical  staffs  of  the  Bureau. 

The  four  major  software  technologies  mentioned  above  are 
strong  contributors  to  generating  software  that  can  be 

modified  with  greater  ease  than  traditional  software.  Thus  : 

their  employment  will  benefit  the  users  by  allowing  a 
more  rapid  tracking  of  the  user's  evolving  requirements. 
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The  enhanced  access  by  the  clerical  staff  will  result  from 
the  adoption  of  an  on-line  plus  batch  philosophy  of  processing 
coupled  with  a  wide  dispersal  of  suitable  terminals  in  the 
offices  of  the  Bureau. 

AIS  is  an  incremental  development,  that  is,  facilities  are 
being  brought  on-line  by  discrete  increments. 

Some  of  these  increments  are  already  operational  and 
enjoying  great  success  (for  instance  the  PRO  system, 
see  Appendix  B) . 

The  ultimate  significance  of  the  AIS  development  rests  on 
accelerating  and  streamling  a  number  of  personnel  assignment 
(distribution),  training,  selection,  etc.  functions  as 
well  as  providing  better  support  of  manpower  and  planning 
activities . 

Simultaneously,  the  AIS  development  is  acting  as  a  catalyst 
for  the  integration  of  manpower/training/personnel  processes 
for  the  following  categories  of  labor: 

Military 

Civilian 

Reserve 

Contractors 

At  a  time  when  better  than  half  of  the  defense  dollar  is 
spent  on  personnel  AIS  promises  to  be  an  inexpensive 
investment  in  improving  the  effectiveness  of  the  Navy. 
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GSG's  activities  during  the  contract  period  consisted  in 
a  number  of  reviews.  Each  review  considered  research, 
architectural  design,  software  engineering,  development 
management  and  procurement  issues. 

This  broad  spectrum  of  issues  was  convered  by  the  use  of 
teams  of  people  with  the  various  expertises  listed  above. 

In  this  final  report  we  will  document  the  two  most 
important  reviews  during  the  contract  year. 

The  first  review  is  concerned  with  a  very  interesting 
applied  research  program  underway  at  Randolph  AFB  by  the 
Military  Personnel  Center  (MPC)  of  the  Air  Force. 

The  review  technical  findings  are  summarized  in  Section  2.0 
of  this  report.  Appendix  A  of  this  report  is  the  original 
GSG  report  on  the  review. 

The  second  major  review  is  an  in-depth  program  review  of  the 
entire  AIS  program  at  Bupers.  Again,  the  technical 
findings  of  this  review  are  summarized  in  Section  3.0  of 
this  report.  Appendix  B  of  this  report  is  the  original 
GSG  report  on  the  review. 
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2 . 0  The  Personnel  Machine 

The  basic  notion  behind  the  personnel  machine  is  to 
maintain  and  enlarge  the  previous  thrusts  of  systems  such 
as  BLPS  and  HAF  core  in  the  direction  of  a  highly 
responsive  flexible  system  design  for  personnel  applications. 
This  is  viewed  as  achievable  via  the  integration  of  a 
number  of  technologies  which  did  not  exist  at  the  time 
that  BLPS  and  HAF  were  first  designed  and  implemented. 

The  specific  technologies  whose  integration  is  contemplated 
are: 

1.  Modern  system  implementation  programming  languages, 
namely  the  technology  of  transportable  software 
for  system  level  software,  as  reflected  by  such 
languages  as  PASCAL  and  ADA  (which  is  PASCAL 
based) . 

2.  The  technology,  that  has  evolved  over  the  last 
decade,  of  modularization  and  stratification  of 
operating  systems,  namely  the  generalization  of 
the  virtual  machine  notions. 

3.  The  integrated  database  technology ,  whose  major 
significance  is  the  more  complete  separation  of 
data  and  procedures  and  the  ability  to  represent 
complex  relationships  amongst  data  in  a  program 
or  procedure  independent  way. 
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4.  The  decision  logic  table  technology  for  application 
programming . 

5.  The  integration  of  certain  key  aspects  of  the 
system  programming  technology  with  the  database 
technology. 

Let's  briefly  review  these  five  items  to  see  what  they  mean. 
Item  1  really  represents  the  adoption  of  a  body  of  recent 
Computer  Sciences  research  on  the  necessary  and  sufficient 
characteristics  of  programming  languages  to  allow  the 
triinsportability  of  system  software.  By  and  large,  this  body 
of  notions  has  not  entered  yet  the  common  industrial  practice 
which  still  rests  largely  on  the  use  of  assembly  languages 
for  system  software.  It  is  also  clear  that  the  long 
term  trend  is  that  these  technologies  will  indeed  be 
used  on  a  wide  basis. 

Point  2  (the  stratification  of  the  OS)  represents  technology 
which  has  entered  industrial  practice  quite  extensively, 
this  project  is  recommending  that  in  addition  to  what  are 
well  accepted  points  about  the  stratification  of  the  inner 
layers  of  the  operating  system  that  a  special  ''personnel 
oriented"  layer  be  constructed.  This  certainly  is  a  good 
recommendation.  Its  implementation  represents  a  novel 
effort  since  it  requires  the  proper  identification  of  a 
set  of  complete  and  possibly  minimal  personnel  primitives. 
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Point  3  again  has  entered  the  industrial  practice,  in  the 
sense  that  many  current  systems  use  integrated  data  base 
technologies.  The  project  is  indicating  a  commitment 
to  the  use  of  relational  database  technology,  common 
industrial  practice  is  still  based  on  the  use  of  hierarchical 
and  network  database  technology,  however,  by  and  large, 
this  technology  is  well  into  practice.  The  Air  Force 
personnel  systems  are  behind  the  times  by  not  having  adopted 
it  sooner. 


Point  4,  namely  the  extensive  use  of  decision  logic  table 
technology  for  the  definition  of  the  application  program 
procedures,  is  the  point  in  which  the  Air  Force  personnel 
experience  has  led  the  way  with  respect  to  industrial 
practice.  In  fact,  one  of  the  major  distinguishing 
characteristics  of  BLPS,  which  is  basically  a  predecessor 
to  HAF,  was  its  strong  commitment  to  the  use  of  DLT's  for 
the  definition  of  procedures  such  as  edits.  The  use  of 
decision  logic  tables  increases  considerably  the  ability  to 
modify  procedures  rapidly  and  efficiently,  and  the  ability 
of  the  non -programming  skilled  personnel  to  bring  about 
such  modifications  or  to  understand  the  modifications  made 
by  somebody  else.  MPC  trailblazed  the  practical  application 
of  DLT's  over  a  decade  ago. 

In  view  of  this  successful  experience  it  is  correct  to 
integrate  it  in  the  new  research.  In  particular,  the  DLT's 
are  not  inconsistent  with  any  of  the  other  notions  above 
so  we  do  not  see  any  problems  with  factoring  this  into 


the  overall  plan. 
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Point  5  is  where  the  project  shows,  in  our  opinion,  the 
greatest  amount  of  technological  innovation,  in  fact  the 
state-of-the-art  is  that  notions  of  datatyping  and  data 
description,  which  are  particular  to  the  modern  programming 
languages,  such  as  PASCAL,  have  not  really  been  related 
with  similar  notions  in  database  data  management  technology. 
Point  5  is  precisely  the  integration  of  these  similar  but 
yet  distinct  notions.  In  other  words,  in  this  area  we 
believe  that  the  project  will  actually  do  a  certain  amount 
of  applied  research  and  tackling  of  not  fully  understood 
or  fully  known  issues.  However,  we  are  confident  that 
this  is  a  necessary  and  potentially  very  useful  integration 
to  accomplish. 

To  better  understand  the  significance  of  integrating  the 
four  technologies  listed  above  it  is  well  to  remember  the 
nature  of  the  fundamental  architectural  tradeoff.  This 
tradeoff  is  a  tradeoff  between  the  modifiability  of  the 
system  and  its  efficient  use  of  computer  resources.  In 
general,  choices  can  be  made  either  in  the  direction  of 
increasing  computer  resources  utilization  or  in  the 
direction  of  increasing  the  ease  with  which  the  system  can 
be  modified,  adapted,  expanded,  etc.,  but  not  both 
simultaneously. 

The  history  of  computer  technology  can  be  viewed  as  a 
progression  towards  increasingly  favoring  the  modifiability 
aspect  over  the  efficiency  aspect.  The  reason  why  computer 
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technology  has  been  moving  in  this  direction  are:  a)  the 
rapidly  decreasing  costs  of  computer  resources  warrants 
less  and  less  preoccupation  with  their  efficient  utilization, 
b)  the  advance  of  Computer  Science  has  improved  the 
understanding  of  a  number  of  modularity  concepts,  that 
while  having  a  price  in  terms  of  efficient  use  of  computer 
resources,  greatly  simplify  the  process  of  building 
a  system,  and  consequently  modifying  it  too,  c)  there 
has  been  a  growing  realization  that  EDP  is  not  an  end  to 
itself,  but  it  is  a  service  function  and  consequently, 
from  an  economic  point  of  view,  one  should  be  concerned  net 
with  the  efficient  utilization  of  computer  resources,  but 
rather  with  the  efficient  utilization  of  the  operational 
resources. 

The  reason  why  we  are  mentioning  this  basic  notion  of 
computer  technology  is  that  the  four  technologies, 
mentioned  above,  and  their  integration  move  in  the 
direction  of  increasing  modularity  and  consequently 
modifiability,  extendability ,  adaptability  of  the  computing 
system.  They  all  have  built  in  some  costs  in  terms  of 
efficiency  of  computer  resources.  So,  that  to  say  that 
one  would  undertake  a  radical  reorientation  of  the  system 
design  along  the  lines  mentioned  above  means  that  one  is 
seeking  a  very  significant  increase  of  modifiability, 
adaptability,  and  expandability  of  the  system  at  the  expense 
of  some  reduction  of  computer  resource  utilization.  We 
believe  that  this  is  indeed  the  right  direction  to  go, 

especially  in  systems  designed  for  personnel  functions. 
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Another  historical  perspective,  that  is  worth  keeping  in 
mind  in  evaluating  this  special  project,  is  that  the 
application  of  computers  started  with  the  mechanization  of 
accounting  and  cost  control  applications,  where  the  field 
of  applications  is  much  less  variable  and  dynamic  than 
personnel.  Later  computer  applications  went  into  the 
personnel  area.  There  is  a  fundamental  difference  between 
the  personnel  applications  and  say  the  accounting 
applications.  Consider,  for  example,  the  case  of 
legislative  (mandated)  changes  to  the  EDP  system.  In 
the  case  of  accounting  systems  changes  to  accounting  rules 
or  accounting  policy  are  rare  and  therefore,  they  materialize 
at  intervals  which  are  long  enough  to  accomodate  ponderous 
change  mechanisms.  In  the  case  of  personnel,  mandated 
changes  are  very  very  frequent,  especially  in  the  last  few 
years  there  has  been  a  veritable  explosion  of  legislation 
in  the  area  of  personnel  benefits,  taxes,  retirement  policies, 
etc.  It  is  thus  very  clear  that  personnel  systems  should 
be  designed  with  a  system  philosophy  which  is  different  than 
that  for  accounting  systems.  This  was  recognized  by  MPC 
even  at  the  time  of  BLPS  and  HAF,  and  the  special  project 
is  simply  further  accentuating  such  a  trend. 
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3 . 0  AIS  Review:  Technical  Issues 

The  operational  experience  accumulated  thus  far  with  the 
PRO  system  allows  an  evaluation  of  the  PRO  architecture. 

This  evaluation  was  presented  to  us  during  the  review  and 
basically  the  results  are  that  the  PRO  distributed  architecture 
succeeds  very  well  in  off-loading  the  central  processor. 

In  fact,  a  considerable  number  of  terminals  can  be 
supported  with  absolutely  negligible  loading  of  the  central 
processor.  However,  while  from  a  performance  point  of 
view,  the  PRO  architecture  has  proved  out  to  be  very 
effective  there  are  serious  misgivings  with  regard  to  its 
availability. 

During  the  presentation  there  was  considerable  discussion 
on  whether  che  availability  problem  arises  from  the  Host, 
or  the  FEP ,  or  the  remote  terminal  processor,  or  the  lines. 

As  a  result  of  the  discussions  we  requested  that  some 
actual  data  be  given  to  us  with  regard  to  scheduled  time, 
available  time,  and  down  time  for  the  three  classes  of 
processors  namely  Host,  FEP,  RTPC. 

The  data  covers  the  four  weeks  of  November  13,  November  20, 
November  27,  and  December  4,  and  they  are  presented  in 


Table  3-1. 
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The  data  is  extremely  significant  and  aaain  illustrates  that 
a  little  bit  of  data  can  cut  through  endless  hours  of 
discussion.  In  fact,  the  data  shows  that  the  host  was 
available  during  those  four  weeks  for  an  average  of 
69.3%  of  scheduled  time,  the  FEP  was  available  during  the 
same  period  for  an  average  of  98.3%  of  scheduled  time, 
and  the  RTPC  was  available  over  the  same  period  for  an 
average  of  96.3%  of  scheduled  time.  From  these  figures 
it  can  be  readily  concluded  that  the  lack  of  availability 
of  PRO  to  the  user  is  largely  determined,  if  not 
exclusively  determined,  by  the  fact  that  the  Host  is 
down  something  like  30.6%  of  scheduled  time.  Therefore, 
the  availability  of  PRO  is  not  the  consequence  of  its 
architecture. 

Our  recommendation  is  thus  to  carry  an  in-depth  study  of  the 
causes  of  such  an  excessive  down  time  for  the  Host.  We 
also  recommend  that  a  management  objective  of  gradually 
reducing  the  Host  down  time  be  set  up.  In  addition, 
consideration  should  be  given  to  increasing  the  amount  of 
scheduled  time  so  that  overall  user  availability  can 
be  improved . 

An  important  architectural  issue  is  what  should  be  the 
implementation  language  for  the  future  of  AIS.  During 
the  presentations  of  the  CORE  systems  program  the  issue 
of  implementation  was  raised,  namely  the  desirability  to 
have  high  level  language  alternatives  to  the  use  of 
assembly  language  (ALC) . 
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Our  recommendation  in  this  area  would  be  that,  provided  that 
the  speed  of  compilation  is  not  extremely  crucial,  and  that 
on  the  other  hand  efficient  object  code  is  an  important 
issue,  AIS  establish  contact  with  various  research  groups  in 
the  country  who  are  experienced  with  PASCAL  and  PASCAL 
transportability  and  bootstrapping  mechanisms.  We  can 
assist  AIS  personnel  in  establishing  these  contacts. 

The  rationale  for  this  recommendation  is  as  follows: 

a)  We  believe  that  the  ADA  initiative  will  succeed 
(over  a  number  of  years) .  ADA  is  PASCAL  derived, 
consequently  a  move  towards  PASCAL  would  be  a 
staging  move  for  an  eventual  adoption  of  ADA 

by  AIS. 

b)  Programming  languages  of  modern  type  such  as 
PASCAL,  ADA  provide  the  tools  for  producing 
software  which  is  not  only  structured  but  is 
also  designed  for  modern  notions  of  portability. 

c)  There  are  already  a  number  of  PASCAL  compilers 
which  are  written  in  PASCAL  therefore  suitable  for 
bootstrapping  the  compiler  onto  one's  own  machine. 

The  most  important  issue  for  the  CORE  systems  area  is  that 
of  the  development  strategy  to  be  pursued  in  light  of 
the  Brand  X  procurement.  Assuming  the  Brand  X  will  proceed 
on  the  present  course  of  a  totally  A-109  procurement,  the 
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planning  of  developments  in  the  CORE  system  area  is  both 
very  difficult  and  very  critical  to  the  success  of  the 
Brand  X  operation. 

From  the  review  we  learned  that  an  effort  to  formulate  a 
CORE  system  design  concept  is  presently  underway.  One  of 
the  very  first  questions  is:  to  what  use  would  such  a  design 
concept  be  put.  The  possible  uses  as  we  see  them  are: 

a)  As  a  blueprint  for  internal  development  to  be 
pursued  once  the  Brand  X  machine  is  available. 

b)  As  a  specification  for  the  Brand  X  procurement. 

c)  As  a  means  to  supply  in-depth  technical  evaluation 
material  to  be  used  during  the  Brand  X  proposal 
selection  phase. 

d)  As  a  blueprint  for  development  to  be  performed 
after  Brand  X  is  known  by  either  the  original 
Brand  X  vendor  or  other  contractors. 

e)  As  a  blueprint  for  both  staging  activities  to  be 
performed  before  the  Brand  X  selection,  and 
developments  after  the  Brand  X  selection,  by 
OP-16  people  augmented  by  contractors. 

It  seems  to  us  that  alternative  a)  is  largely  to  be  excluded 
because  the  limited  development  resources  are  already 
completely  applied  to  short  term  development  goals. 
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Alternative  b)  has  to  be  excluded  because  it  is  contrary  to 
the  spirit  and  the  letter  of  A-109.  Alternative  c) ,  d) , 
and  e)  are  all  of  significant  interest. 

In  the  case  of  alternative  c)  the  design  concept  for  CORE 
systems  could  be  a  source  of  technical  evaluation  factors 
with  great  power  of  discrimination  and  selectivity.  Since 
there  is  no  question  that  after  Brana  X  has  been  selected 
the  evolution  of  CORE  systems  will  have  to  continue.,  it 
follows  that  alternative  d)  will  be  of  interest  in  guiding 
the  further  work  of  the  Brand  X  vendor  and  associated 
contractors.  However,  the  most  interesting  use  of  a 
design  concept  for  CORE  systems  is  really  alternative  o) . 
This  alternative  really  contemplates  staging  activities 
that  could  be  performed  before  the  Brand  X  is  installed. 

What  we  are  referring  to  is  that,  while  for  the  application 
systems  the  Brand  X  procurement  concept  will  guarantee,  that 
they  will  transition  correctly  to  Brand  X,  nothing  of  the 
kind  is  available  for  CORE  systems. 

Furthermore,  to  insist  that  a  transition  benchmark  be  used 
for  CORE  system  as  well  as  application  systems  could  be 
construed  as  being  contrary  to  predominant  procurement 
doctrine  and  A-109.  The  reason  why  CORF  systems  cannot 
be  incorporated  in  a  transition  benchmark  is  that  it  is 
very  difficult,  if  not  impossible  to  assert  that  CORE 
system  functionality  is  directly  related  to  mission 
requirements . 
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Since  CORE  systems  cannot  be  incorporated  in  transition 
benchmark,  the  alternative  is  to  stage  the  CORE  systems 
so  that  equivalent  functionality  can  be  guaranteed  after 
the  transition. 

We  recommend  thus  that  the  present  CORE  system  design  concept 
study  be  redirected  to  formulate  a  set  of  requirements  and 
a  development  plan  for  CORE  systems  to  aid  the  transition 
to  Brand  X.  Such  a  requirement  study  and  plan  should 
define  the  portions  of  CORE  systems  which  will  be 
implemented  by  a  standard  off-the-shelf  vendor  supplied 
software  and  the  portion  of  CORE  systems  which  will  not. 

For  the  portion  that  will  not  be  implemented  through  off- 
the-shelf  vendor  supplied  software  the  plan  should  formulate 
a  series  of  staging  development  activities  aimed  at  bringing 
such  portions  of  the  CORE  software  into  a  transportable 
implementation . 

To  clarify  further  what  we  are  talking  about  let  us  look  at 
something  like  MUM.  First  the  determination  should  be 
made  that  the  likelihood  of  having  the  same  functionality 
from  many  of  the  standard  industrial  vendors  is  low  and 
consequently  that  MUM  would  have  to  be  transitioned  to  Brand  X. 
After  having  made  such  a  determination  one  should  examine 
the  present  implementation  of  MUM  and  decide  whether  or  not 
it  is  intrinsically  transportable  to  most  other  vendor 
environments.  If  it  is  not  one  should  schedule  a 
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reimplementation  of  MUM  in  suitable  language  and  system 
conventions  to  guarantee  its  portability  to  a  Brand  X 
environment. 

A  good  example  of  this  policy  of  staging  towards  a  greater 
reliance  on  the  resources  offered  by  the  industry,  is  given 
by  the  potential  policy  with  regard  to  report  writers.  As 
we  understand  it  the  present  policy  is  to  maintain  a  home 
grown  report  writer.  We  believe  that  this  policy  is  not 
very  satisfactory  from  at  least  two  respects.  One  is  that 
it  ties  up  precious  in-house  development  resources,  the  other 
is  that  a  single  report  writer  cannot  really  span  the  wide 
interests  and  priorities  of  multiple  user  communities. 

The  present  industry  situation  with  regard  to  report  writers 
that  are  capable  of  interfacing  with  the  TOTAL  DBMS  is  that 
there  are  several  with  different  focus  and  optimization. 

For  instance  Easytrieve  is  optimized  for  casual  inquiry, 

Mark  IV  is  optimized  for  formal  reporting,  besides  these 
two  one  should  consider  also  Culprit  and  Socrates. 

We  thus  recommend  tha t ,  in  line  with:  saving  of  internal 
development  resources,  easier  staging  to  Brand  X  and 
satisfying  in  a  better  way  the  user  communities,  AIS 
consider  the  adoption  of  a  policy  of  having  multiple  report 
writers  commonly  marketed  in  the  industry  and  capable  of 
interfacing  with  the  TOTAL  DBMS. 
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Both  during  the  presentations  of  the  CORE  system  program 
and  those  of  the  U&QC  function  the  topic  of  dedicated 
initiators  came  up.  A  scheduling  policy  based  on  the  use 
of  dedicated  initiators,  controlling  partitions  dedicated 
to  particular  users  of  the  AIS  system,  leads  to  potential 
under  utilization  of  the  mainframe  computer  resources. 

On  the  other  hand  such  a  policy  can  be  a  wise  policy  in  the 
initial  phases  of  an  integration  in  so  far  that  it  can  give 
a  guarantee  of  priority  control  to  a  specific  user  community. 

In  light  of  the  two  above  considerations  we  recommend  that 
AIS  pursue  the  development  of  a  general  purpose  resource 
allocator  for  its  mainframe  facility,  and  that  the 
individual  cases  of  dedicated  initiator  be  reviewed 
periodically  (at  least  once  every  six  months)  at  the 
OP-16  staff  level  to  determine  whether  continuation  of  such 
privelege  is  still  warranted.  These  reviews  should  generate 
a  trend  towards  the  elimination  of  such  special  handling 
of  resource  allocation  over  a  period  of  time.  Thus,  a  more 
efficient  utilization  of  computer  resources  will  result 
without  any  traumatic  impact  on  user  communities. 
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Conunents  on  the  Randolph,  AFB  Visit  on  Behalf  of  Bupers 

Introduction 

On  July  11  and  12,  1978  a  team  composed  of  Mr.  W.  Poteat 
and  J.  Kramer  of  Bupers,  and  U.  0.  Gagliardi  of  GSG,  Inc. 
visited  the  Randolph  Air  Force  Base  to  talk  to  the  special 
project  group  of  MPC.  The  purpose  of  the  visit  was  to 
obtain  information  regarding  a  conceptual  effort  underway 
at  MPC.  The  effort  is  concerned  with  potential  technology 
directions  and  system  development  directions  for  the  evolution 
of  the  Headquarter  Air  Force  (HAF)  personnel  system. 

This  effort  had  been  brought  to  the  attention  of  Bupers 
management  by  Lt.  Col.  Thomas  Lee  as  of  potential  interest 
and  relevance  to  the  Bupers  AIS  effort.  Thus,  one 
of  the  charges  of  our  team  was  to  determine  whether  such 
interest  was  indeed  justified. 

In  Randolph  we  were  exposed  to  a  number  of  briefings  that 
clearly  conveyed  to  us  the  purpose,  objectives,  and  nature 
of  the  activities  of  the  special  project.  It  became  very 
clear  that  this  special  project  is  not,  and  should  not,  be 
considered  a  development  project  since  it  is  a  conceptual 
exploration  of  possible  directions.  We  will  amplify  on  this 
point  in  these  notes. 
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The  departure  point  for  the  effort  was  an  extensive  and 
critical  review  of  the  current  status  and  structure  of  th 
HAF  system. 

HAF  is  one  of  three  interacting  levels  of  systems  that  the 
personnel  arm  of  the  Air  Force  uses  for  the  management  of 
personnel  resources.  The  other  two  levels  of  systems 

are  the  Base  level  systems  (BLPS)  which  is  deployed  as  about 
a  hundred  twenty  bases  and  the  MAJCOM  system  which  is  deployed 
at  about  a  dozen  or  so  of  major  commands.  MPC  views 
the  three  levels  of  systems  as  an  integrated  system,  vertically 
integrated  system,  where  transactions  originated  from  one 
level  of  system  can  flow  to  another  level  of  system  causing 
update  and  synchronization  of  information. 

The  critical  review  was  concerned,  as  we  understand  it,  with 
only  the  top  level  system,  namely  the  headquarter  system  (HAF) . 

The  result  of  the  critical  review  can  be  briefly  summarized 
as  follows: 

1.  HAF  consists  of  a  core  (which  accounts  for  about 
40%  of  the  total  system)  and  a  very  large  number 
of  subsystems.  The  core  is  driven  by  design 
concepts  which  are  very  similar  to  those  of  BLPS. 
Most  important  aspect  of  that  similarity  is  the 
extensive  adoption  of  table  driven  concepts  for 
the  implementation  of  the  application  (  functional) 


software. 


2.  The  numerous  HAF  subsystems  are  characterized  by 
being  basically  unrelated  subsystems,  implemented 
in  ad  hoc  fashion,  to  respond  rapidly  to  pressing 
requirements . 

3.  HAF  does  not  use  modern  database  technology.  It 
is  based  on  the  use  of  traditional  flat  files, 
in  the  form  of  nine  Master  Personnel  Files  and 
many  hundreds  of  special  files,  most  of  which 

are  really  extracts  from  the  MPF's.  The  fact  that 
^o  many  MPF's  extracts  are  used  causes 
serious  problems  with  the  concurrency  of  the 
information. 

The  overall  assessment  of  the  review  is  th>  t:  a)  60%  and  growing 
percentage  of  HAF  is  ad  hoc,  unrelated  subsystems,  developed 
under  no  common  guiding  architectural  principles,  b)  only  the 
core  of  IIAF  is  table  driven,  c)  the  complex  collection  of 
files  (many  specific  to  one  of  these  subsystems)  whose  contents 
have  to  be  derived  from  the  Master  files  presents  increasingly 
serious  problems  to  the  maintenance  of  the  total  system. 

The  critical  review  study  comes  to  die  conclusion  that  many  of 
the  operationally  apparent  problems  with  HAF  are  only  symptons 
of  the  more  fundamental  problems  stated  above  and  that  until 
they  are  solved  the  symptoms  of  course  will  not  disappear. 


This  study  concludes  that  treating  each  symptom  separately, 
by  local  modifications  to  the  existent  system,  would  not  be 
effective  and  would  be  dispersive  of  energy.  Consequently, 
what  is  needed  is  a  redo  of  the  system,  that  would  permit  the 
integration  of  several  modern  technologies,  and  the  adoption 
of  a  clean  base  which  would  solve  all  of  the  problems  in  a 
permanent  way. 

Due  to  the  rapid  evolution  of  computer  technology  in  the  areas 
of  hardware  capabilities,  programming  techniques,  data  management 
techniques,  and  architectural  design  techniques  it  is  always 
true,  from  a  purely  technical  point  of  view,  that  the  best 
solution  is  to  start  from  scratch  and  design  from  what  are  cur¬ 
rently  correct  principles.  So  we  have  no  real  qualms  with  the 
conclusion  reached  by  tho  study.  The  reason,  why  many  organi¬ 
zations  do  not  do  it,  is  that  they  have  the  pressure  to  solve 
immediate  problems  and  not  enough  discretionary  resources  to 
allow  a  calm  and  sheltered  design  along  modern  technological 
directions . 

In  other  words,  if  an  organization  is  not  in  a  position  to  have 
a  modest  but  highly  qualified  set  of  resources  for  a  feasibility 
and  first  rough  prototyping  effort,  it  should  not  undertake  it, 
because  undertaking  radical  redesign  activities  in  connection 
with  the  commitment  to  replace  and  supplant  on  going  systems 
never  works. 
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The  reason  why  it  does  not  work  is  that  the  pressures  to  de¬ 
crease  development  risks  are  so  high  that  automatically  one  is 
driven  towards  minimizing  the  amount  of  technological  innova¬ 
tion  permitted  in  the  project. 
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The  Personnel  Machine 


After  completing  the  critical  review  of  HAF  the  special 
project  addressed  the  issue  of  formulating  an  alternative 
for  it.  This  alternative  is  called  the  Personnel  Machine. 

The  basic  notion  behind  the  personnel  machine  is  to  main¬ 
tain  and  enlarge  the  previous  thrusts  of  systems  such  as 
PLPS  and  HAF  core  in  the  direction  of  a  highly  responsive 
flexible  system  design  for  personnel  applications.  This  is. 
viewed  as  achievable  via  the  integration  of  a  number  of  tech¬ 
nologies  which  did  not  exist  at  the  time  that  BLPS  and  HAF 
were  first  designed  and  implemented.  The  specific  technologies 
whose  integration  is  cotemplated  are: 

1.  Modern  system  implementation  programming  languages, 
namely  the  technology  of  transportable  software 
for  system  level  software,  as  reflected  by  such 
languages  as  PASCAL  and  D0D1  (which  is  PASCAL 
based) . 

2.  The  technology,  that  has  evolved  over  the  last 
decade,  of  modularization  and  stratification  of 
operating  systems,  namely  the  generalization  of  the 
virtual  machine  notions  and  the  Dijkstra  notions. 


3.  The  integrated  database  technology,  whose  major 
significance  is  the  more  complete  separation  of 
data  and  procedures  and  the  ability  to  represent 
complex  relationships  amongst  data  in  a  program 
or  procedure  independent  way. 

4.  The  decision  logic  table  technology  for  application 
programming. 

5.  The  integration  of  certain  key  aspects  of  the 
system  programming  technology  with  the  database 
technology . 

Let's  briefly  review  these  five  items  to  see  what  they  mean. 

Item  1  really  represents  the  adoption  of  a  body  of  recent 
Computer  Sciences  research  on  the  necessary  and  sufficient 
characteristics  of  programming  languages  to  allow  the  transpor¬ 
tability  of  system  software.  By  and  large,  this  body  of  notions 
has  not  entered  yet  the  common  industrial  practice  which  still 
rests  largely  on  the  use  of  assembly  languages  for  system  soft¬ 
ware.  It  is  also  clear  that  the  long  term  trend  is  that  these 
technologies  will  indeed  be  used  on  a  wide  basis. 

Point  2  (the  stratification  of  the  OS)  represents  technology 
which  has  entered  industrial  practice  quite  extensively,  this 
project  is  recommending  that  in  addition  to  what  are  well  accep¬ 
ted  points  about  the  stratification  of  the  inner  layers  of  the 
operating  system  that  a  special  "personnel  oriented"  layer  be 
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constructed.  This  certainly  is  a  good  recommendation.  Its 
implementation  represents  a  novel  effort  since  it  requires 
the  proper  identification  of  a  set  of  complete  and  possibly 
minimal  personnel  primitives. 

Point  3  again  has  widely  entered  the  industrial  practice 
in  the  sense  that  many  current  systems  use  integrated  data 
base  technologies.  The  project  is  indicating  a  commitment 
to  the  use  of  relational  databse  technology,  common  industrial 
practice  is  still  based  on  the  use  of  hierarchical  and 
network  database  technology,  however,  by  and  large  this  tech¬ 
nology  is  well  into  the  practice.  The  Air  Force  personnel 
systems  are  behind  the  times  by  not  naving  adopted  it  sooner. 

Point  4,  namely  the  extensive  use  of  decision  logic  table 
technology  for  the  definition  of  the  application  program 
procedures,  is  the  point  in  which  the  Air  Force  personnel 
experience  has  led  the  way  with  respect  to  industrial  practice. 
In  fact,  one  of  the  major  distinguishing  characteristics  of 
BLPS ,  which  is  basically  a  predecessor  to  HAF,  was  its  strong 
commitment  to  the  use  of  DLT's  for  the  definition  of  procedures 
such  as  edits.  The  use  of  decision  logic  tables  increases 
considerably  the  ability  to  modify  procedures  rapidly  and  eff- 
ciently,  and  the  ability  of  the  non-programming  skilled 
personnel  to  bring  about  such  modifications  or  to  understand 
the  modifications  made  by  somebody  else.  This  is  definitely 
a  point  where  the  MPC  experience  was  a  trailblazing  type  of 


experience  and  it  seems  only  right  that  it  be  folded  into  an 
integration  of  new  technologies  effort.  In  particular, 
the  DLT's  are  not  inconsistent  with  any  of  the  other  above 
notions  so  we  do  not  see  any  problems  with  factoring  this 
into  the  overall  plan. 

Point  5  is  where  the  project  shows  in  our  opinion  the  greatest 
amount  of  technological  innovation,  in  fact  the  state-of-the 
art  is  that  notions  of  datatyping  and  data  description,  whic.i 
are  particular  to  the  modern  programming  languages  such  as 
PASCAL,  have  not  really  been  related  with  similar  notions  in 
database  data  management  technology.  Point  5  is  precisly 
the  integration  of  these  similar  but  yet  distinct  notions. 

In  other  words,  in  this  area  we  believe  that  the  project  will 
actually  do  a  certain  amount  of  applied  research  and  tackling 
of  not  fully  understood  or  fully  known  issues.  However,  we 
are  confident  that  this  is  a  necessary  and  potentially  very 
useful  integration  to  accomplish. 

To  better  understand  the  significance  of  integrating  the 
four  technologies  listed  above  it  is  well  to  remember  the 
nature  of  the  fundamental  architectural  tradeoff.  This 
tradeoff  is  a  tradeoff  between  the  modifiability  of  the 
system  and  its  efficient  use  of  computer  resources.  In  general, 
choices  can  be  made  either  in  the  direction  of  increasing 
computer  resources  utilization  or  in  the  direction  of  increasing 
the  ease  with  which  the  system  can  be  modified,  adapted  expanded, 
etc. ,  but  not  both  simulataneously . 
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The  history  of  computer  technology/  can  be  viewed  as  a  progres¬ 
sion  towards  increasingly  favoring  the  modifiability  aspect  over 
the  efficiency  aspect.  The  reason  why  computer  technology  has 
been  moving  in  this  direction  are:  a)  the  rapidly  decreasing 
costs  of  computer  resources  warrants  less  and  less  preoccupation 
with  their  efficient  utilization,  b)  the  advance  of  Computer 
Sciences  has  improved  the  understanding  of  a  number  of  modularity 
and  separation  of  interface  and  similar  other  concepts,  that 
while  having  a  price  in  terms  of  efficient  use  of  computer 
resources,  greatly  simplify  the  process  of  building  a  system, 
and  consequently  modifying  it  too,  c^  there  has  been  a  growing 
realization  that  EDP  is  not  an  end  to  itself,  but  it  is  a 
service  function  and  consequently,  from  an  economic  point  of 
view,  one  should  be  concerned  not  with  the  efficient  utilization 
of  computer  resources,  but  rather  with  the  efficient  utilization 
of  the  operational  resources. 

The  reason  why  we  are  mentioning  this  basic  notion  of  computer 
technology  is  that  the  four  technologies,  mentioned  above,  and 
their  integration  move  in  the  direction  of  increasing  modularity 
and  consequently  modifiability,  extendability ,  adaptability  of 
the  computing  system.  They  all  have  built  in  some  costs  in 
terms  of  efficiency  of  computer  resources.  So,  that  to  say 
that  one  would  undertake  a  radical  reorientation  of  the  system 
design  along  the  lines  mentioned  above  means  that  one  is 
seeking  a  very  significant  increase  of  modifiability,  adaptability, 


v-***^v 


i 


and  exapandability  of  the  system  at  the  expense  of  some  reduction 
of  computer  resource  utilization.  We  believe  that  this  is 
indeed  the  right  direction  to  go,  especially  in  systems  designed 
for  personnel  functions. 

Another  historical  perspective,  that  is  worth  keeping  in  mind 
in  evaluating  this  special  project,  is  that  the  application 
of  computers  started  with  the  mechanization  of  accounting 
cost  control  type  of  applications  and  moved  on  to  the  inventory 
control  type  of  applications  where  the  field  of  applications 
is  much  less  variable  and  dynamic  than  personnel.  Later 
computer  applications  went  into  the  personnel  area.  There  is  a 
fundamental  difference  between  the  personnel  applications  and 
say  the  accounting  applications.  Consider,  for  example,  the 
case  of  legislative  (madated)  changes  to  the  EDP  system. 

In  the  case  of  accounting  systems  changes  to  accounting  rules 
or  accounting  policy  are  rare  and  therefore,  they  materialize 
at  intervals  which  are  long  enough  to  accomodate  ponderous 
change  mechanisms.  In  the  case  of  personnel,  mandated  changes 
are  very  very  frequent,  especially  in  the  last  few  years  there 
has  been  a  veritable  explosion  of  legislation  in  the 
area  of  personnel  benefits ,  taxes,  retirement  policies,  etc. 

It  is  thus  very  clear  that  personnel  systems  should  be  designed 
with  a  system  philosophy  which  is  different  than  that  for  account¬ 
ing  systems.  This  was  recognized  by  MPC  even  at  the  time  of 
BLPS  and  HAF,  and  the  special  project  is  simply  further 


accentuating  such  a  trend. 
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Significance  to  Bupers 

We  now  turn  to  the  question  of  what  does  this  all  mean  to 
Bupers  and  the  AIS  project. 

The  Advance  Information  System  (AIS)  development  at  Bupers 
is  in  response  to  an  urgent  need  of  the  Navy  to  move  its 
personnel  support  systems  from  a  batch  oriented  type  of 
philosophy  t  <  an  interactive  computing  philosophy.  In  other 
words,  the  Navy  has  been  engaged  in  the  last  few  years  into  a 
system  development  that  would  allow  terminals  to  be  put  into 
the  functional  users  offices  for  the  direct  use  by  the  personnel 
clerks  to  perform  personnel  actions  such  as  assignments,  etc. 

In  connection  with  this  effort,  Bupers  has  also  undertaken 
the  introduction  of  modern  database  technology  as  the 
underpinning  of  the  data  management  of  the  new  system. 

To  put  this  Navy  effort  in  perspective,  one  must  realize 
that, except  for  the  different  data  management  technologies 
involved,  from  the  functional  point  of  view  the  Bupers  effort 
is  equivalent  to  the  effort  that  the  Air  Force  undertook 
about  a  decade  ago  with  the  introduction  of  BLPS  and  later  on 
HAF.  So,  in  our  opinion  the  Navy  is  basically  in  urgent  catch 
up  mode,  not  so  much  to  catch  up  with  computer  technology,  as 
to  use  a  minimum  amount  of  new  computer  technology  that  would 
allow  a  significant  and  drastic  revolution  of  the  way  the 
personnel  clerks  operate  in  their  job. 
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The  point  is  that  the  Navy  objectives,  at  this  point  in  time, 
and  those  of  the  Air  Force  are  different.  The  Navy  has  an 
urgent  need  to  catch  up  with  the  Air  Force,  in  terms  of  achieving 
a  more  capillary  dispersion  of  computer  support  to  its  staff 
so  to  achieve  more  efficient  personnel  operation  and  a  reduction 
of  the  human  resources  dedicated  to  such  processes.  This  is  so 
that  a  better  control  be  gained  of  the  personnel  inventory. 

The  Air  Force,  by  and  large,  has  already  achieved  it  for  a 
number  of  years  so  the  Air  Force  goal,  at  this  point,  should 
not  be  the  rapid  implemention  of  an  operational  system,  but 
rather  the  goal  is  to  ask  questions  about  what  are  the  directions 
along  which  further  progress  can  be  made. 

So,  one  obvious  consequence  of  this  is  that  the  two  timetables 
are  not  compatible.  The  Navy  requires  technologies  and  system 
designs  that  can  be  brought  on  stream  very  rapidly,  like  in 
the  next  two  years.  The  special  project,  although  its  notions, 
especially  technological  are  excellent,  will  not  have  a  chance 
to  make  a  real  contribution  to  the  present  AIS  effort  because 
it  could  not  possibly  contribute  within  the  next  couple  of  years. 

This  is  not  to  say  that  the  Navy  should  ignore  the  project 
completely.  It  would  be  a  mistake  to  consider  it  a  project 
that  could  make  a  contribution  on  a  short  term  and  should  not 
be  viewed  that  way.  However,  in  the  long  term,  in  the  five 
to  .en  year  type  of  range,  this  project  could  make  some  very 
very  significant  contributions  to  both  the  Air  Force  and  the  Navy 
personnel  systems.  So,  the  conclusion  we  reach  is  that  the 
Navy  should  do  no  more  than  monitor  this  project  and  its  tech- 


nological  evalution.  In  our  opinion,  this  monitoring  could  be 
effective  if,  at  least  one  Navy  person  would  participate,  for 
at  least  a  year,  with  the  special  project  team.  This  person 
should  have  proper  qualifications,  that  means  that  he  should 
be  a  recent  graduate  from  a  Computer  Science  program,  a  Ph.D. 
in  Computer  Sciences  would  be  the  best  choice  for  a  Navy  parti¬ 
cipant  in  the  special  project  team. 

Inclosing,  we  recommend  that  the  Navy  send  a  recent  Ph.D.  in 
Computer  Sciences  for  a  period  of  a  year  to  be  a  fully  parti¬ 
cipating  member  of  the  special  project  team  at  Randolph  AFB , 
and  that  the  Navy  does  not  consider  this  project  as  a  develop¬ 
ment  project  capable  or  producing  outputs  that  could  be  factored 
into  the  MS  plan  in  the  next  two  or  three  years.  The  latter 
would  be  a  serious  mistake  that  would  result  in  confusion  and 
harm  to  both  the  Navy  and  the  Air  Force.  On  the  other  hand,  the 
full  participation  and  monitoring  of  the  technological  aspects 
of  this  special  project,  we  think  would  be  a  minor  investment 
that  would  be  well  justified  in  terms  of  preparing  the  Navy  to 
undertake, five  to  ten  years  from  now, the  further  evolution  of 
AIS. 


G.  S.  G.,  lnr. 
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1.0  Management  Summary 

This  report  presents  the  findings  of  the  GSG  review  of  the  AIS 
Project  held  on  December  12  and  13,  1978. 

In  this  summary  we  will  cover  only  those  findings  which  require 
for  their  resolution  the  involvement  of  management  higher 
then  OP-16.  The  body  of  the  report  contains  numerous  additional 
issues  which  can  be  resolved  internally  to  OP-16,  the  data 
processing  development  and  operation  organization  of  the  Bureau 
of  Personnel. 

Section  3  (Organizational  Issues)  presents  a  single  issue  worth 
noting  in  this  summary  namely  the  difused  nature  of  the  Decision 
Support  System  charter  (see  Section  3.4). 

Decision  Support  System  (DSS)  is  the  branch  of  OP-16  that  is 
in  charge  of  developing  models  in  support  of  the  planning  and 
programming  activities  of  the  Bureau.  The  diffused  charter 
arises  from  the  need  to  preserve  most  of  the  development 
resources  within  the  functional  user  organizations.  Namely, 
about  90%  of  £.11  development  resources  in  this  area  are  really 
in  the  hands  of  the  ultimate  users.  This,  as  we  stated,  is 
a  necessity  given  the  nature  of  the  work,  however,  has  its 
negative  consequences. 

A  negative  consequence  is  that,  at  least  for  some  of  the 
programs,  in  particular  NAMPS,  we  see  a  lack  of  accountability 
and  a  lack  of  management  focus.  To  remedy  this  situation 
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we  recommend  that  at  uhe  OP-01  staff  level  steps  be  taken  to 
grant  to  the  head  of  DSS  the  power  to  veto,  or  at  least  concur¬ 
rence,  with  the  expenditure  of  funds  and  personnel  resources 
on  DSS  projects. 

In  Section  4  (Management  Mechanisms)  there  are  two  issues  worth 
noting.  The  first  one  has  to  do  with  the  present  structure 
of  the  various  plans  that  control  the  AIS  development  (see 
Sections  4.4  and  4.5).  The  second  one  has  to  do  with  the 
tracking  actual  benefits  realized  by  AIS  applications  and  systems 
(see  Section  4.3). 

The  first  issue  can  be  best  presented  by  giving  our  recommendation 
which  is  that  all  of  the  plans  that  control  the  AIS  development 
should  be  organized  in  a  strictly  hierarchical  structure. 

That  is  it  should  be  perfectly  clear  which  of  two  plans  is 
the  controlling  plan.  With  the  controlling  plan  of  course 
overriding  any  contradictions  stated  by  the  subordinate  plan. 

We  further  recommend  that  the  following  hierarchy  be  adopted: 

-  MANT PAPERS  Plan 

AIS  Strategic  Plan  (which  should  include  the  architectural 
plan  and  the  financial  plan) 

Program  Plans 

Project  Plan 
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Furthermore,  it  is  essential  that  the  MANTRAPERS  Plan  be 
completed  as  readily  as  possible  to  a  level  of  articulation 
that  spells  out  action  level  recommendations  in  addition  to 
the  present  specification  of  objectives  and  policies. 

The  second  significant  issue  (see  Section  4.3)  is  the  tracking 
of  benefits  realized  by  ADP  applications.  At  first  sight  it 
may  appear  that  such  tracking  is  very  difficult  to  do,  however, 
a  moment  of  reflection  shows  that  such  difficulty  is  more 
apparent  than  real. 

The  key  concept  is  that  benefits  must  be  defined,  at  the  proposal 
stage  (ADS) ,  so  that  they  can  be  measured  and  therefore  tracked. 
That  is,  a  proposal  should  be  approved  only  if  its  cost/benefit 
analysis  includes  only  those  benefits  which  the  organization  is 
capable  of  measuring.  Thus,  our  recommendation  in  this  area  is 
very  simply: 

Do  not  accept,  as  part  of  a  cost/benefit  analysis,  benefits 
which  the  organization  cannot,  or  does  not  know  how,  to  measure. 
Furthermore,  adopt  the  practice  of  periodically  reviewing  benefit 
projected  and  benefit  realized  after  the  ADP  application  has 
gone  operational. 


Section  4  of  the  report  (resources)  has  a  number  of  noteworthy 
issues  which  we  will  present  below. 

Probably  the  most  fundamental  issue  is  the  chronic  lack  of 
resources,  that  is  personnel  resources.  Over  the  years  that 
we  have  reviewed  AIS  and  its  predecessor  developments,  this 
has  been  a  constant  issue.  In  this  report  we  are  assuming 
that  in  the  foreseeable  future  no  additional  people  will  be 
made  available  to  the  AIS  development  and  consequently  we  are 
shaping  our  recommendations  to  confront  this  reality.  Our 
key  recommendation  is  as  follows: 

Move  towards  a  personnel  mix  with  a  higher  level  of  skills 
and  therefore  a  higher  percentage  participation  of  higher 
grade  positions.  This  should  enable  the  organization  to  be 
able  to  rely  more  extensively  on  contracting  and  therefore 
to  use  fewer  billets. 
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During  the  review  information  was  supplied  to  us  indicating  that 
the  percentage  of  higher  grade  (GS-13,  GS-14,  GS-15)  in  OP-16 
and  NMPC-16  is  below  the  average  for  Navy  ADP  organizations. 

Such  statistics  would  indicate  that  the  above  recommendation  is 
a  very  realistic  one  and  in  fact  that  Bupers  might  be  facing 
a  serious  problem  in  this  area. 

In  addition  to  the  above  major  recommendation  we  have  the 
following  subordinate  recommendations : 

Get  more  personnel  prepared  and  trained  in  the  skills 
required  in  controlling/monitoring  contracts. 

Contract  for  products/services  instead  of  bodies. 

Contract  out  the  inner  part  of  the  system  and  do  in- 
house  the  outer  parts  of  the  system. 

The  present  practice  is  just  the  opposite  of  what  we 
are  recommending ,  although  the  OP-16  organization  is 
moving  in  the  direction  that  we  are  recommending. 

The  basic  rationale  for  our  recommendation  is  that 
the  inner  part  of  the  system  are  more  universally 
valid  and  tend  to  be  less  directly  impacted  by  mission 
related  requirements.  The  opposite  is  true  of  course 
for  the  outer  parts  of  the  system. 
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report  has  recommended,  the  OP-16  director  billet  should  be 
a  civilan  billet  to  insure  the  continuity  of  the  leadership 
in  this  function.  Continuity  of  leadership  in  information 
system  development  is  an  absolute  must  since  development  times 
are  easily  of  the  order  of  several  years,  especially  when 
fundamental  technological  transitions  are  being  performed 
such  as  in  the  case  of  AIS. 

We  strongly  believe  that  the  director  of  OP-16  has  to  have  the 
stature  to  be  on  equal  footing  with  the  Admirals  that  head  up 
the  various  subdivisions  of  OP-01,  this  means  that  such  a 
civilian  should  be  of  the  stature  which  in  private  industry 
would  be  considered  Vice-Presidential  level.  That 
in  turn  implies  that  a  super  grade  classification  GS-16/17 
should  be  obtained  for  this  billet.  Failure  to  obtain  a  super 
grade  classification  will  result  in  an  inability  to  secure 
the  proper  kind  of  management  talent  with  very  serious 
consequences  to  the  AIS  program. 

During  the  review  we  obtained  evidence  indicating  very  serious 
classification  problems  with  two  development  branches  of  the 
MNPC-16  organization.  The  branches  in  question  are  the  MIS, 
which  is  responsible  for  the  development  of  application  systems 
supporting  all  of  the  major  operational  processes  of  Bupers. 


The  other  branch  is  CORE  which  is  responsible  for  the  development 


of  foundation  system  software.  We  believe  that  the 
classification  problems  are  arising  because  the  classifiers 
are  having  difficulty  in  grasping  the  fact  that  design  talent 
and  design  ability  which  is  present  at  the  OP-16  level,  in  the 
office  of  the  System  Architect, is  complimentary  and  not  a 
replacement  of  the  design  talent  that  has  to  exist  at  the 
development  branch  level  such  as  MIS  and  CORE. 

We  therefore  recommend  that  a  renewed  approach  be  attempted  to 
the  classifiers  to  obtain  the  proper  classif ication  in  higher 
grades  for  the  management  positions  in  these  critical  development 
branches . 

The  final  and  very  critical  issue  in  the  area  of  resources  is  the 
lack  of  committed  funding  for  the  Brand  X  procurement.  As  we 
understand  it, the  Brand  X  procurement, in  order  to  be  compatible 
with  predominant  procurement  doctrine  for  EDP  systems, will 
have  to  expend  the  following  sums  of  money,  $3  million  in  1980, 

$7  million  in  1981,  $8  million  in  1982,  $7  million  in  1983, 
and  $4  million  in  1984  for  a  total  of  $29  million.  Again  as 
we  understand  it, this  funding  has  been  submitted  in  one  of  the 
POM's  but  it  is  at  the  bottom  of  the  priority  list  with  no 
guarantee  that  it  will  be  authorized. 

A  complimentary  issue  is  that  of  whether  or  not  the  Brand  X 
procurement  should  be  pursued  by  accepting  the  constraint  of  IBM 
compatibility. 
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The  issue  in  question  is  that;  if  a  constraint  of  IBM  compatibility 
is  authorized, then  the  procurement  would  still  be  competitive. 

In  fact  the  nature  of  the  industry  is  such  that  IBM 
compatibility  now-a-days  still  implies  multiple 
suppliers  available,  however  one  would  avoid  a  very  complex 
and  expensive  conversion  benchmark  exercise  and  therefore 
reduce  the  monies  required  by  the  procurement.  It  is  our 
guess  estimate  that  IBM  compatibility  would  reduce  the  cost 
of  the  Brand  X  procurement  by  something  like  $20  million. 

In  light  of  the  two  above  issues  we  recommend  the  following: 

The  Programming  and  Plans  function  of  OP-16  should  periodically 
(at  least  once  every  six  months)  te'st  whether  or  not 
the  higher  monitoring  authorities  would  grant 
permission  to  use  IBM  compatibility  as  a  constraint 
to  the  procurement.  P&P  should  have  the  support  of 
higher  management  in  Bupers  and  the  Navy  in  general 
since  this  action  would  save  considerable  monies  and 
noticeably  reduce  the  technical  risk  of  the  procurement. 


At  the  level  of  OP-01  and  the  ASN  (FM)  the  funding 
situation  of  Brand  X  should  be  firmed  up  and  clarified. 
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Section  6  of  the  report  (Development/Technical  Issues/Status) 
presents  three  issues  which  are  worth  the  attention  of  higher 
management. 

Both  in  order  to  move  to  a  Brand  X  machine,  and  in  light  of  our 
recommendation  to  start  relying  on  industry  sources  for  the  inner 
part  of  the  system,  the  development  policy  in  the  area  of  CORE  systems 
should  be  carefully  thought  out.  The  purpose  of  such  careful  re¬ 
thinking  should  be  to  maximize  the  ability  of  the  Bureau  to  utilize 
standard  off-the-shelf  software  and  to  correspondingly  curtail 

the  activities  leading  to  homegrown  system  software.  Consequently 
we  are  recommending  that  (see  Section  6.2): 

The  CORE  system  design  concept  effort  presently  underway,  be 
redirected  to  yield  requirements  (for  evaluation  purposes) 
and  a  development  plan  supporting  the  transition  to  Brand  X 
(staging  to  Brand  X) .  Such  a  development  plan  should  clearly 
segregate  the  portions  of  the  CORE  software  that  can  be 
implemented  by  off-the-shelf  industry  offerings  from  those 
portions  which  cannot  be  replaced  by  off-the-shelf  industry 
offerings . 

For  the  latter  pert  of  the  software  the  development  plan  should 
spell  out  specific  development  activities  aimed  at  transforming 
the  software  into  transportable  implementations.  That  is  the 
development  plan  should  offer  guidance  on  how  homegrown  system 
software  will  be  staged  into  a  transportable  form  that  would 
allow  it  to  be  bootstrapped  onto  Brand  X  when  Brand  X  is  available. 
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The  second  development  issue  refers  to  the  SDS  project  which  is 
the  foundation  for  the  Pay  and  Personnel  (see  Section  6.3)  con¬ 
solidation  project,  PASS.  The  issue  is  that,  because  of  procedural 
and  data  entry  differences  ,  at  present  three  SDS  '  s  are  emerging  ;  a  military, 
a  civilian,  and  reserve  versions.  While  we  recognize  that 
some  of  the  differences  are  justified  we  believe  that  it  is 
very  important  that  an  effort  be  made  to  prevent  the  evolution 
of  three  separate  SDS's,  therefore  we  recommend: 

Formally  document  all  of  those  differences  in  the  military, 
civilian,  reserve  application  which  demonstrated ly  have  heavy 
procedural  impact  on  the  user. 

The  rationale  for  our  recommendation  is  that  the  very  effort 
of  formally  documenting  such  differences  will  involve  the 
separate  functional  users  and  will  put  the  spotlight  on 
the  differences  forcing  an  automatic  reduction  of  such  differences. 

In  addition,  once  they  are  all  formally  documented  it  will 
be  possible  to  hold  an  independent  review  and  resolution  of 
additional  differences.  We  believe  that  this  effort  will  result 
into  the  ability  to  implement  a  single  SDS  which  will  have 
a  limited  number  customizations  for  the  military,  civilian, 
reserve  cases. 

The  final  development  issue  we  would  like  to  mention  is  the  continuing 
evidence  that  the  turnaround  of  application  development  is  poor. 

(See  Section  6.3.)  What  we  are  talking  about  is  that  the 
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ultimate  user  sees  a  rather  long  period  of  time  between  the 
formulation  of  a  request  for  a  new  ADP  application  and  the 
actual  application  coming  on  stream.  To  solve  this  problem 
we  recommend  the  following: 

Adopt  a  policy  that  no  application  ADP  project  be  approved 
that  is  not  capable  of  committing  a  first  release  operational 
capability  to  the  user  18  months  or  sooner  after  the  finalization 
of  agreed  upon  functional  requirements.  Alternatively  the 
policy  could  require  that  a  first  release  of  an  operational 
capability  be  committed  by  the  24  month  from  the  start  of 
the  project  where  the  24  months  period  would  include  also 
the  finalization  of  functional  requirements. 

There  is  increasing  evidence  that  shows  that  this  policy  is 
not  only  dosireable  but  is  entirely  feasible. 

Our  final  recommendation  is  concerned  with  the  area  treated  in 
Section  7  of  the  report  (User  Interface)  and  is  as  follows: 

In  future  reviews  representative  of  the  0P-1X  using  communities 
should  brief  the  GSG  team  on  a  recent  user  acceptance 
experience . 

The  rationale  for  this  recommendation  is  that  it  will  give 
the  GSG  team  an  opportunity  to  see  a  more  balanced  presentation 
of  the  activities  o f  ATS  by  obtaining  first  hand  feedback 
from  the  users  of  thei>"  experiences  with  the  AIS  products  and 
services . 
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We  would  like  to  close  this  management  summary  by  stressing 
that,  while  the  above  put  the  spotlight  on  issues  and  unresolved 
problems,  we  were  very  favorably  impressed  by  the  speed  and 
depth  with  which  OP-16  has  qrown  into  the  recently  adopted 
organization.  This  new  organization  reflects  extensive 
industrial  practice  and  recent  insights  regarding  the  software 
development  process.  We  were  also  impressed  by  the  extent 
with  which  the  first  goal  of  the  AIS  development,  the 
consolidation  of  the  computing  resources,  has  been  achieved 
essentially  on  time.  Finally,  the  breadth  and  the  quality 
of  the  presentations  given  to  us,  and  the  openness  of  the 
discussions  was  extremely  refreshing  and  a  positive  indicator 
that  OP-16  is  moving  confidently  on  with  the  job  at  hand. 


a.  s.  a.,  inr. 
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2 . 0  Introduction 

This  report  documents  the  findings  of  the  review  of  the 
Advanced  Information  System  (AIS)  Program  at  Bupers.  The 
review  was  conducted  by  GSG,  Inc.  on  December  12  ana  13,  1978. 

The  findings  of  the  review  are  organized  in  five  sections 
as  follows: 

Section  3  -  Organizational  Issues  will  report  the 
findings  regarding  the  practical  implementation 
of  the  charters  of  the  various  suborganizations 
within  OP-16. 

Section  4  -  Management  Mechanisms  will  report 
findings  relating  to  mechanisms  for  the  control 
of  the  processes  and  the  resources  of  OP-16. 

Section  5  -  Resources  will  discuss  issues  relating 
to  various  resources  that  OP-15  employs  for  its  mission. 

Section  6  -  Development/Technical  Issues/Status  will 
report  all  of  the  issues  which  have  to  do  with  the 
development  process  itself. 

Section  7  -  User  Interface  will  document  issues  that 
have  to  do  with  the  effectiveness  with  which  OP-16 
re1 ates  to  the  user  community. 
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In  occasion  of  this  review  GSG  received  two  major  impressions 
which  we  would  like  to  report  in  this  introduction.  The  first 
is  that  we  are  very  pleased  with  the  considerable  progress 
that  has  been  made  by  OP-16  in  adopting  and  implementing  the 
organizational  ideas  and  processes  which  were  formulated 
at  the  Fort  Richie  Retreat  in  the  Summer  of  '77.  We  believe 
that  now  OP-16  has  the  kind  of  organizational  structure  that 
is  required  for  the  successful  undertaking  of  an  ambitious 
project  such  as  AIS.  During  the  review  we  had  plenty  of 
opportunity  to  witness  how  the  managers  have  identified  with 
their  role  in  the  new  structure,  although  there  are  still 
problems,  there  is  no  question  that,  overall,  the  new 
structure  has  taken  hold  of  the  organization. 

The  second  key  impression  relates  to  the  degree  and  quality  of 
preparation  for  the  review.  There  is  no  question  that  tnis  _ 
review  was  the  best  we  have  attended  at  Bupers.  The  program 
was  well  laic,  out,  the  individual  managers  had  done  considerable 
effort  in  preparing  concise  presentations.  The  review  had 
a  clear  overall  theme.  In  other  words,  a  truly  professional 
job  was  accomplished . 


(!.  S.  Inc. 
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3 . 0  Organizational  Issues 
3.1  PCO  Role 

The  first  item  we  would  like  to  discuss  is  the  role  of  the 
Program  Control  Office  (PCO) .  The  role  of  this  office 
is  to  be  delicately  balanced  in  such  a  manner  as  tc  avoid 
the  fundamental  problem  of  a  tree  structured  organization 
without  demotivating  the  line  managers. 

The  only  human  organizations  that  v;ork  are  tree  structured 
organizations.  In  fact,  only  for  such  organizations  respon¬ 
sibility  can  be  properly  delegated  by  retaining  accountability. 
However,  tree  structured  organizations  do  not  lend  themselves 
very  well  to  the  development  of  information  systems  since  not 
always  is  it  possible  to  partition  the  system  into  a  tree 
structure.  As  a  result  one  always  ends  up  with  development 
projects  which  will  span  across  the  responsibility  and 
accountability  boundaries  of  the  development  line  managers. 

It  is  for  these  reasons  that  a  PCO  office  is  needed  to  guarantee 
that  those  issues  that  go  across  the  boundaries  of  the  line 
managers  are  not  neglected  or  not  suboptimized  by  the  individual 
managers . 

If  the  PCO  on  the  other  hand  becomes  a  second  guessing  tool 
in  support  of  higher  management,  it  is  perceived  as  a  form 
of  restricted  or  subordinate  delegation  and  therefore  it  can 
be  extremely  demotivating.  We  recommend,  therefore,  that  the 
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PCO  be  carefully  restricted  to  track  those  projects,  such  as 
SDS,  which  will  span  across  several  line  managers  (in  the 
case  of  SDS  for  instance  CORE  and  MIS  are  both  involved) . 

The  general  rule  should  be  that  if  an  issue  is  clearly  under 
the  responsibility  of  one  of  the  line  program  managers  then 
the  PCO  should  have  no  involvement  with  it  except  maybe  to 
stay  informed  of  the  status. 
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3 . 2  Project  Tracking 

Another  important  issue  is  where  project  tracking  belongs. 
Possibilities  are  the  Plan  and  Program  (P&P)  function,  the 
PCO,  the  line  program  managers  (PM's). 

First  of  all  there  are  two  kinds  of  tracking  processes 
in\olved.  One  is  the  purely  job  cost  accounting  tracking 
which  will  track  actual  expenditure  versus  the  development 
plans  supporting  budget  authorizations.  The  second  kind 
of  tracking  tracks  the  actual  degree  of  completion  of 
the  project  versus  development  plans. 

The  financial  tracking  should  be  part  of  the  P&P  function  which 
i  •  the  responsible  agent  for  synthesizing  the  budget  submissions 
and  consequently  would  be  the  best  place  where  to  track  the 
actual  expenditure  of  financial  resources. 

The  physical  completion  track  has  two  separate  issues.  The 
first  issue  is  the  method  with  which  such  a  track  could  be 
achieved.  We  will  not  discuss  this  in  this  report,  however, 
we  plan  to  at  a  later  date  give  some  input  on  this  issue. 

It  suffices  to  say  that  the  issue  of  obtaining  a  reliable 
physical  completion  track  for  information  systems  is  not  a 
trivial  one.  Assuming  that  such  an  issue  has  been  solved 
and  the  tools  are  on  hand  to  perform  such  a  track  the 
question  is  then  should  the  PM  do  it  or  should  the  PCO  do  it. 


C.  S.  I nr. 
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Our  answer  to  the  last  question  is  that  for  projects  which  are 
entirely  under  the  responsibility  of  the  PM  the  PM  should 
perform  the  actual  tracking  process.  However,  the  PM  should 
make  the  tracking  information  available  for  information  only 
to  the  PCO  office  upon  request  from  the  PCO  office.  The 
only  tracking  that  should  be  performed  by  the  PCO  office  is 
tracking  of  physical  completion  of  projects  that  involve 
more  than  one  PM. 


G.  S.  Inr, 
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3 . 3  CORE  Project  Initiation 

The  fact  that  the  CORE  project  initiation  policy  has  not  been 
completed  is  a  disturbing  indicator.  We  interpret  this 
indicator  to  be  a  sign  that  the  relative  charters  of 
System  Architecture  and  CORE  systems  have  not  been  sufficiently 
clarified  or  accepted  by  the  corresponding  managers. 

We  also  understand  that  lack  of  time  and  an  unresolved 
difference  of  opinion  with  P&P  regarding  the  need  for  an 
economic  analysis  are  the  extant  reasons  for  this  policy  not 
being  ready. 

Our  experience  shows  that  economic  analyses  are  difficult  if 
not  impossible  for  CORE  systems  and  that  the  alternative  is 
to  rely  on  the  system  architect  to  provide  objective  justifica¬ 
tion  for  CORE  systems  projects.  In  fact,  most  of  the  objective 
justification  of  such  projects  lies  in  the  rationalization  of 
the  overall  system  architecture.  The  latter  in  turn  is  a 
strong  supporting  element  of  the  cost/effectiveness  of  ADP 
applications . 

As  we  see  it  the  System  Architect  role  is  to  act  for  CORE  in  the 
same  manner  as  P&P  acts  for  the  application  programs  and 
products.  Namely,  the  System  Architect  should  distill,  condense 
and  abstract  the  requirements  that  are  levied  by  the  application 
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systems  against  the  CORE  system  and  it  should  be  able  to 
formulate  a  set  of  abstracted  functional  requirements  for 
CORE  systems.  Furthermore,  the  System  Architect  office  should 
be  able  to  lay  out  an  architectural  plan  that  would  indicate 
over  the  long  term  how  the  CORF  system  facilities  hardware 
and  software  would  evolve. 


21 


3.4  DSS  Charter 

The  DSS  charter,  because  of  the  special  nature  of  the  modelling 
work,  has  still  a  rather  diffused  nature  to  it.  For  instance, 
of  about  200  people  who  are  involved  in  modelling  activities, 
only  about  25  report  directly  to  the  DSS  PM.  This  makes 
for  a  situation  where  OP-16  and  the  DSS  PM  do  not  have 
sufficient  control  on  DSS-like  activities.  Another  indicator 
of  this  lack  of  control  is  that  the  single  largest  project 
NAMPS,  which  by  itself  accounts  for  about  half  of  the  total 
resources  in  the  DSS  area,  appears  to  not  have  a  sharp  focal 
point  of  management. 

Our  recommendation  to  improve  the  situation  is  to  secure  an 
authorization  power  for  the  DSS  PM  on  the  resource  expenditure 
of  all  DSS  projects.  In  other  words,  what  we  are  saying 
is  that  we  fully  realize  that  many  DSS  projects,  in  order  to 
be  successful,  will  have  to  be  done  within  the  user  structure. 
However,  one  should  at  least  insist  that  the  DSS  PM  has 
a  concurrence  veto  on  whether  resource  expenditure  is  allowed 
or  not  for  a  specific  DSS  project. 

Another  small  problem  with  the  DSS  charter  is  that  it  appears 
that  some  MIS  work  is  still,  because  of  historical  reasons, 
in  the  collections  of  projects  overseen  by  DSS.  We  recommend 
that  a  plan  for  gradual  transfer  of  the  MIS  work  to  the  MIS 
branch  be  formulated. 


Ct.  S.  (».,  Itir. 
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3 . 5  Training 

An  important  charter  issue  is  where  the  training  of  new  OP-16  and 
NMPC-16  employees  should  be  performed.  The  present  OP-16  policies 
indicate  that  training  is  performed  by  the  System  Architect  office. 

In  industry  one  sees  two  kinds  of  solutions  with  regard  to 
training.  A  centralized  solution  versus  a  decentralized 
solution.  If  the  centralized  solution  is  adopted  usually 
training  is  done  by  the  System  Architect  office  since 
this  is  the  corporate  resource  which  has  the  most  technical 
background  of  what  is  going  on  in  the  development  shops  and 
it  also  has  always  the  charter  for  following  and  tracking 
developing  technologies.  In  the  decentralized  solution 
training  is  delegated  to  the  organization  which  will  actually 
absorb  the  new  recruit.  Like  many  organizational  issues 
there  are  pros  and  cons  to  both  forms  of  training.  The  basic 
tradeoff  is  that  decentralized  training  is  faster,  however,  the 
employee  starts  with  a  parochial  view  of  the  organization  and 
its  activities  and  therefore  has  a  lower  capability  of  being 
reutilized  in  other  suborganizations. 

Exactly  the  converse  is  true  in  the  case  of  centralized 
training . 

Elsewhere  we  recommend  that  OP-16  consciously  adopt  policies 
aiming  at  reducing  its  staff  numbers  but  increasing  the 
representation  of  high  skill  levels  in  its  job  mix.  The  resulting 


(>.  S.  I  nr. 


24 


4 . 0  Management  Mechanisms 
4 . 1  QA  Mechanisms 

The  notions  presented  to  us  by  the  U&QC  function  regarding 
quality  control  are  not  acceptable.  The  basic  notion  is 
a  very  ambitious  and  very  expensive  program  for  tracking 
down  and  mapping  the  consistency  of  multiple  levels  of  technical 
documentation  with  assistance  of  a  contractor.  This  is  not 
necessary.  It  is  expensive  and  it  will  totally  demotivate 
the  development  groups  who  are  producing  this  technical  documenta¬ 
tion  . 

Traditionally  quality  control  is  performed  by  an  independent 
organization  that  reports  to  the  head  of  the  data  processing 
organization  and  limits  its  determination  of  quality  to  an 
external  view.  The  key  concept  is  that  the  head  of  the  data 
processing  organization  has  to  have  an  independent  input  in 
making  the  decision  to  release  the  product  to  the  field. 

This  independent  view  point  comes  from  a  Quality  Assurance 
or  Quality  Control  organization  which  tests  the  product  strictly 
from  a  user  point  of  view,  that  is  the  black  box  point  of 
view,  without  having  any  understanding  of  its  internals  and 
its  mode  of  operation.  Vast  industrial  experience  shows  that 
Quality  Control  that  is  done  with  the  absence  of  inside 
knowledge  of  how  the  product  works  is  much  more  likely  to 
simulate  realistically  the  kind  of  abuse  and  mistakes  that 
users  will  make  in  using  the  product.  So  the  general  concept, 
that  is  widely  accepted  in  the  industry, is  that  QA  is  performed 
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by  starting  from  the  user  manuals  with  a  staff  of  people,  who 
know  nothing  about  the  product  except  what  is  in  the  user 
manuals,  and  they  try  to  use  it  as  specified  by  the  user 
manuals  and  report  whatever  discrepancies  exist.  This  approach 
to  QA  results  in  quality  controlling  not  only  the  software 
and  the  hardware  but  also  the  user  manuals. 

We  strongly  recommend  that  U&QC  limit  itself  to  this  traditional 
type  of  Quality  Control. 


<;  .S',  <• 
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4 . 2  User  Acceptance  Testing 

During  the  discussions  held  at  the  review  the  issue  of  user 
acceptance  also  came  up.  It  should  be  understood  that  user 
acceptance  testing  is  different  from  Quality  Control.  Usually 
user  acceptance  testing  is  negotiated  at  the  time  the 
development  project  is  authorized  or  during  the  early  stages 
of  the  development  project  with  the  user  specifying  the  kind 
of  tests  that  he  would  like  to  perform  for  his  own  acceptance. 
Another  important  point  is  that  user  acceptance  testing 
occurs  after  QA  is  finished.  That  is,  OA  determines  whether 
the  product  can  be  released  to  the  users  in  the  first  place. 
After  the  product  is  released  to  the  user,  the  user  has  the 
opportunity  to  accept  it  or  reject  it  on  the  basis  of  has 
own  testing.  This  testing  is  aimed  at  not  only  determining 
general  quality  of  the  software  ,  but  also  primarily 
determine  whether  the  software  satisfies  the  functional 
specifications  and  performance  specifications  the  user  laid 
out  in  the  original  contract. 

Since,  in  the  case  of  the  Bupers  environment,  the  user  does  not 
actively  participate  as  a  contracting  entity,  one  may  want  to 
adopt  a  slightly  different  approach.  U&QC  could  be  charged  to 
cooperate  with  the  user  in  assisting  him  in  setting  up  its  own 
acceptance  testing  procedure.  But  still  the  fundamental 
point  is  that  the  user  acceptance  tests  should  in  some  way  be 
legimately  formulated  by  the  ultimate  user. 


G.  S.  G.,  Inc. 
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4 . 3  Tracking  Physical  Completion  and  Realized  Benefits 

Management  tracking  mechanisms  for  tracking  the  degree  of 
physical  completion  and  benefits  realized  by  a  particular 
EDP  project  are  presently  absent.  GSG  will  provide  in  future 
papers  some  guidance  on  suitable  management  tracking  mechanisms 
for  the  physical  completion  of  information  processing  projects. 

As  far  as  tracking  actually  realized  benefits  the  issues  is  not 
so  much  of  mechanisms  as  an  issue  of  willingness.  There  are 
two  basic  problems  that  interfere  with  the  willingness  to  do 
an  actual  track  of  benefits.  One  is  the  perception  on  the  part 
of  the  user  organization  that  if  benefits  are  visibly  documented 
that  this  may  result  in  curtailment  of  resources.  The  other 
issue  is  that  the  benefits  projected  in  the  development  plan 
are  usually  not  formulated  in  a  manner  that  allows  quantification. 

The  first  issue  is  usually  a  pseudo  problem  because  in  general 
the  introduction  of  information  processing  systems  does  reduce 
the  resource  required  to  do  the  original  work,  however,  the 
real  impetus  for  their  introduction  is  the  fact  that  the  work¬ 
load  is  escalating  faster  than  the  resource  expansion  rate  would 
permit.  So,  we  believe  that  this  first  problem  can  be 
overcome  if  in  the  projection  of  the  benefits  one  would  put 
the  whole  benefit  picture  in  a  realistic  perspective,  that  is 
of  showing  actually  how  workload  future  expansion  is  coped  with 
by  the  introduction  of  the  information  system. 
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The  second  issue,  surprisingly  enough,  is  actually  resolved 
by  a  commitment  to  track  realized  benefits.  That  is,  once 
a  corporate  willingness  to  track  realized  benefits  is  achieved 
then,  at  the  time  of  approval  of  the  project,  there  will  be 
ample  scrutiny  of  whether  projected  benefits  are 
quantifiable  and  therefore  trackabie  or  not. 
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4 . 4  Relationship  Between  the  AIS  Plans 

The  relationship  of  the  various  AIS  plans  is  represented  in 
the  strategic  plan  in  a  way  which  causes  some  concern. 

During  the  presentation  it  was  explained  to  us  that  the 
graphical  representation  given  for  the  relation  between  the 
various  plans  was  for  the  purpose  of  indicating  how  they 
actually  were  being  developed.  The  representation  in  question 
shows  that  the  program  plans  the  MANTRAPERS  plan,  and  the 
strategic  plan  interact  with  each  other  in  a  kind  of  a  close 
loop  process.  This  of  course  illustrates  well  the  iterative 
nature  of  these  processes.  However,  it  is  very  important 
to  commit  to  a  hierarchical  relationship  between  these  plans. 

The  correct  hierarchical  relationship  between  the  plans  should 
be  as  follows:  the  MANTRAPERS  plan  should  be  the  dominating 
plan,  below  it  the  strategic  plan  should  be  the  dominant 
AIS  plan,  the  strategic  plan  should  subsume  the  architectural 
plan  and  the  financial  plan,  the  strategic  plan  in  turn  should 
control  all  of  the  program  plans  and  then  finally  the  program 
plans  should  control  the  project  plans.  A  higher  hierarchical 
plan  controls  a  lower  plan  in  the  sense  that  if  a  lower  plan 
asserts  anything  which  is  in  contradiction  with  the  higher 
plan,  the  higher  plan  prevails. 
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4 . 5  MANTRAPERS  Plan  Improvement 

Another  problem  with  the  plans  is  that  the  MANTRAPERS  plan 
needs  improvement  in  the  direction  of  expressing  concrete 
actions  to  be  performed  to  fulfill  the  objectives  presently 
expressed  by  the  plan.  This  improvement  has  been  called  for 
by  the  GAO  report  and  it  is  also  needed  in  order  to  tie  the 
AIS  strategic  plan  to  the  MANTRAPERS  plan. 
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4 • 6  Multi-Vendor  Environment  Control  and  Job  Cost  Accounting 

Two  other  important  management  mechanisms  which  are  still  not 
articulated  in  OP-16  are:  1)  mechanism  for  the  control  of  a 
multi-vendor  environment  and  2)  mechanism  for  doing  complete 
job  cost  accounting  for  a  structure  where  there  are  projects 
reporting  to  programs,  programs  reporting  to  organizational 
entities  such  as  MIS,  DSS,  etc.  and  with  cross  reporting 
taking  place  at  several  levels  of  the  hierarchy. 

This  is  not  the  place  to  treat  both  of  these  subjects  since 
they  are  quite  complex.  We  will  do  so  in  future  notes. 
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4 . 7  Approval  of  DPSR's 

The  final  management  mechanism  issue  is  that  of  the  control 
of  the  DPSR’s.  This  issue  is  not  new  to  us,  in  fact,  we 
discussed  it  in  the  first  couple  of  reviews  of  Bupers  and 
its  activities.  We  recommended  at  the  time  that  a  formal 
approval  procedure  be  set  up  so  that  DPSR's  which  exceeded 
certain  threshholds  of  effort  would  actually  require  explicit 
approval  rather  than  being  informally  shoved  into  the  queue 
of  work  to  be  done. 

The  motivation  that  we  had  in  mind,  at  the  time  we  recommended 
this,  was  that  the  bulk  of  the  development  resources  of 
Bupers  were  in  the  PERS-3c  organization  doing  maintenance 
and  enhancement  work  of  the  current  system  with  very  little 
resources  left  for  the  predecessor  of  A1S  (MAPMIS) . 

We  believe  that  a  formal  procedure  was  evolved  and  adopted  and 
as  a  result  of  that  a  considerable  amount  of  PERS-3c  resources 
were  freed  up  and  made  available  for  the  future  MAPMIS 
project.  Probably  all  that  is  required  at  this  time  is  a 
review  of  the  DPSR's  approval  procedure  to  see  whether  it 
is  really  still  being  followed  and  whether  the  threshholds 
that  were  set  at  the  time  are  still  adequate. 
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It  might  very  well  be  that,  since  AIS  has  now  overcome  the 
conflicts  between  current  system  and  AIS  through  a  much  more 
integrated  approach  to  the  organization  and  the  development 
process,  the  threshholds  that  were  set  up  at  the  time 
are  much  too  high.  The  threshholds  may  be  set  up  in  such  a 
way  that  DPSP's  of  something  like  a  couple  of  dozen  man 
months  are  still  getting  through  without  any  formal  approval 
other  than  that  of  the  PM.  It  would  be  a  simple  matter  to 
establish  that  any  DPSR  that  exceeds  12  man  months  level  of 
effort  requires  the  approval  of  OP-16  or  his  designee  in  order 
to  be  committed. 


( S.  Inc. 
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5 . 0  Resources 

Throughout  all  of  the  presentations  the  theme  of  lack  of 
resources  was  a  constant  refrain-  There  is  very  little 
question  in  our  mind,  especially  in  view  of  the  history 
of  the  last  three  years,  that  significantly  larger  personnel 
resources  or  dollar  resources  are  not  forthcoming  and 
consequently  the  only  constructive  approach  is  to  look  at 
the  deployment  of  current  resources  and  see  whether  a  shift 
of  resource  mix  can  get  the  job  done. 

This  section  of  the  report  approaches  the  problem  from 
the  point  of  view  that  total  number  of  billets  is  likely  to 

t 

stay  constant  or  even  decrease.  In  other  words,  the  basic 
recommendation  underlying  everything  we  are  going  to  say  in 
this  section  is  to  move  in  the  direction  of  an  organization  that 
has  higher  level  of  skills  and  consequently  higher  grades 
and  is  more  capable  of  planning  and  defining  work  to  be  performed 
by  outsiders,  namely  contractors.  We  believe  that  this  is  in 
line  with  general  government  policies. 
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On  the  issue  of  staffing  we  have  the  following  recommendations: 

a)  Plan  on  evolving  into  an  organization  with  fewer 
billets  and  people  and  a  higher  percentage  of 
higher  grade  (GS-13,  GS-14,  GS-15)  grades. 

Such  a  personnel  stance  would  be  much  more 
supportive  of  activities  such  as  the  Brand  X 
procurement  and  in  general  a  heavier  emphasis 
on  control  of  contracts. 

b)  For  continuity  and  stability  increase  the  civilian 
component  of  the  personnel  mix  in  DSS. 

c)  We  see  serious  classification  problems  in  the 
CORE  and  MIS  branches.  We  believe  that  these 
problems  are  due  to  the  fact  that  the  classifiers 
have  had  difficulty  in  grasping  the  relative  role 
of  the  System  Architect  office  and  that  of  the 
CORE  and  MIS  development  groups. 

These  classif ication  problems  must  be  overcome  and 
we  would  be  glad  to  assist  in  any  way  possible  to 
convince  classifiers  that  the  CORE  and  MIS  positions 
are  equally  important  than  those  of  the  system 
Architect . 


G.  S.  (!.,  I  nr. 
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d)  We  are  completely  convinced  that  the  OP-16  director 
billet  CLn  order  to  be  filled  by  a  civilian 
as  is  recommended  by  the  GAO  report)  should  be 
a  super  grade  (GS-16  GS-17)  billet.  This  is 

because  the  Director  has  to  have  a  managerial 
stature  comparable  to  that  of  the  Admirals  on 
OP-01  staff.  That  is  he  has  to  be  of  Vice- 
Presidential  caliber. 


We  would  like  to  address  the  issue  of  priority  guidance  for 
positions  within  the  OP-16  organization .  The  way  we  will 
approach  that  is  to  give  for  each  suborganization  priorities 
for  grades  and  for  number  of  billets.  That  is,  given 
a  particular  organization,  which  one  of  its  own  sub¬ 
organizations  should  have  priority  on  the  higher  grade  billets 
and  which  one  should  have  priority  on  the  number  of  billets. 

OP-16:  the  priorities  for  the  staff  of  OP-16  are,  as  we  see  it, 
as  follows:  priority  for  higher  grades  SA,  P&P,  PCO. 

Priority  for  number  of  billets,  P&P,  SA,  PCO. 

NMPC-16  priority  for  higher  grades  DSS,  MIS,  CORE,  U&QC,  FM. 
Priority  for  number  of  billets,  MIS,  CORE,  DSS,  U&QC,  FM 
(assumes  the  facility  management  contract  will  be  entered 
in)  .  If  such  a  contract  is  not  entered  in  then  the  last 
priority  structure  should  be  revised  to:  FM,  U&QC,  MIS, 

CORE,  and  DSS. 
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MIS:  Since  we  received  no  information  from  the  director  of 

the  branch  we  will  only  give  a  priority  indication  based  on 
projects  as  follows:  NMDAS ,  SDS#  officer  order  writing  module, 
enhancements  to  enlisted  men  systems. 

CORE:  We  have  a  single  priority  for  both  higher  grades  and 

number  of  billets  as  follows:  distributed  processing,  data 
management,  host  processing. 

For  the  System  Architect  office,  for  which  we  have  detailed 
staffing  information,  the  priority  for  both  grades  and 
number  of  billets  would  be,  in  our  opinion:  application 
integration,  standards,  support  integration. 

The  other  major  resource  issue  is  funding,  namely,  it  appears 
that  present  budgets  for  the  POM  cycle  81  do  have  any 
allocations  for  the  Brand  X  procurement  but  they  are  low 
priority  items  which  may  not  receive  authorization.  The  Brand  X 
procurement  it  appears  would  require  something  like  3,  7,  8, 

7,  4  million  dollars  respectively  in  1980,  81,  82,  83  and  84 
for  a  grand  total  of  $29  million  which  appear  not  be  allocated 
in  the  budgets  for  that  time  frame.  The  financial  situation 
as  we  understand  it  could  get  worse,  that  is  even  the  presently 
planned  budgets  could  be  further  reduced  by  something  like 
10%  in  which  case  we  understand  the  SDS  project  would  be 
seriously  delayed. 
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The  fundamental  message  is  that  if  the  incremental  funding  of 
some  $29  million  is  not  made  available  over  the  period  1980  -  84 
the  Brand  X  procurement  will  not  come  to  pass  and  that  if 
there  is  a  budget  cut  then  the  SDS  project  may  be  significantly 
delayed. 


a.  s',  a  ,  h w. 
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6 . 0  Development/Technical  Issues/Status 

In  this  section  we  will  describe  a  number  of  issues  and  concerns 
related  to  the  various  development  activities  underway  in  the 
AIS  program.  For  clarity  of  presentation  the  issues  are 

segrated  into  a  number  of  subsections.  Subsection  6.1  will 
cover  issues  related  to  System  Architecture,  section  6.2  the 
issues  related  to  CORE  systems,  section  6.3  MIS  related  and 
finally  6.4  miscellaneous  issues.  During  the  review  no 
development  issues  surfaced  with  respect  to  DSS  activities. 

This  is  primarily  because  the  presentations  that  were  made 
addressed  issues  of  management  mechanisms  and  status  as  opposed 
to  the  actual  development. 


(!.  S.  (!.,  Inc. 
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6 . 1  System  Architecture  Issues 

The  November  21,  1978  draft  of  the  AI3  Architecture  Plan,  in 
intent,  covers  all  of  the  important  areas  of  architectural 
definition  for  AIS.  That  is  the  proposed  table  of  content  appears 
to  us  to  be  satisfactory.  However,  the  draft  is  primarily 
an  annotated  table  content,  that  is  except  for  minor  portions 
the  plan  is  still  a  plan  to  do  the  plan.  It  is  very  important 
that  the  actual  architectural  plan  be  produced,  at  least  in  the 
preliminary  draft  form,  as  soon  as  possible. 

In  other  words,  we  recommend  that  the  present  table  of  content 
be  expanded  very  rapidly  (in  a  matter  of  weeks) ,  at  least  as 
a  first  pass  and  a  discussion  type  of  draft,  since  this  will 
help  in  jelling  a  number  of  ideas  very  rapidly.  It  can  also 
help  in  providing  guidance  to  the  DSS,  MIS,  CORE  development 
processes . 

The  Brand  X  procurement  is  being  approached  at  present  from  the 
perspective  of  complying  with  A-109.  This  implies  that  a 
procurement  package  which  specifies  mission  related  (functional) 
requirements  would  be  presented  to  the  industry  in  an  open 
competition.  Such  an  open  competition  is  very  likely  to 
result  in  a  number  of  participating  competitors  which  are 
not  in  any  way  at  all  compatible  with  IBM  machine  architecture 
and  system  conventions.  It  follows  that  a  very  high  risk  for 
the  transition  of  the  AIS  software  onto  the  Brand  X  machine 
exists . 
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To  protect  the  government  from  this  high  level  of  risk  it  has 
been  decided  that  the  approach  that  wil2  be  followed  in  the  Brand 
X  will  include  two  benchmarks-  One  being  the  traditional 
benchmark  for  cost  performance  evaluation  of  the  competitois, 
and  the  other  being  a  transition  benchmark.  That  is  a  selected 
group  of  application  system  s,  which  are  mission  critical  and 
technically  difficult  to  transition, would  be  transitioned  by 
the  vendors  under  a  multiply  funded  transition  contract. 

This  approach  to  the  Brand  X  procurement  is  of  course  expensive 
and  as  we  remarked  in  Section  5.0  Resources,  there  is  a  definite 
issue  of  the  absence  of  the  funding  for  such  an  approach. 

It  is  projected  that  in  the  years  1980  -  1984  the  Brand  X 
procurement  following  this  approach  would  cost  about  $29  million. 
It  can  be  anticipated  that  a  procurement  approach  that  would 
assume  IBM  compatibility  would  cost  as  much  as  $20  million. 

Therefore  the  fundamental  tradeoff  for  the  3rand  X  procurement  is, 
on  one  hand  the  $29  million  additional  costs,  and  of  course  the 
greater  complexity  and  length  of  the  procurement, and  on  the 
other  hand  the  ability  to  truly  have  a  completely  open  approach 
to  the  marketplace.  During  the  review  discussion  the  point 
was  made  that  probably  the  AIS  management  should  continuously 
test  the  assumption  that  IBM  compatibility  would  not  be  allowed 
as  a  constraint  of  the  procurement  by  higher  monitoring 
authorities . 


(,'.  .S'.  (,..  I  nr. 
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Although  frcr;.  our  general  experience  of  procurements  of  this 
sort,  we  do  not  believe  that  a  variance  to  A-109  policy 
(formulation  of  IBM  compatibility  as  a  constraint  to  the 
procurement)  will  be  permitted.  We  agree  that  P&P  should 
periodically  test  whether  or  not  a  waiver  for  IBM  compatibility 
can  be  obtained. 

The  reason  to  recommend  this  is  that  the  nature  of  the  industry 
is  evolving  very  rapidly,  and  IBM  compatibility  does  not  any 
longer  mean  IBM  products  and  neither  does  it  mean  a  very 
restricted  marketplace.  In  fact,  the  number  of  firms  which  are 
capable  of  offering  look-alike  and  plug  compatible  replacements 
for  increasing  portions  of  the  system,  especially  in  the  case 
of  IBM  systems,  is  growing  very  rapidly.  Therefore,  we  think 
that  it  is  only  prudent  management  to  make  sure  that,  _s  more 
and  more  information  is  obtained  on  the  costs  and  the  risks 
of  the  fully  open  competitive  approach,  the  procurement 
assumptions  be  revalidated  with  very  top  authorizing  authorities. 

Another  important  issue,  in  the  area  of  system  architecture,  is 
the  study  of  the  various  alternatives  to  SDS.  This  issue 
was  precipitated  by  the  GAO  report  which  called  for  a  study  of 
alternative  ways  of  distributing  processing  in  support 
of  SDS.  We  understand  that  we  will  receive  shortly  the  study 
on  alternatives  and  we  will  comment  on  that  study  upon  receipt. 


a.  .s'.  Itw. 
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Tl  a  operational  experience  accumulated  thus  far  with  the 
PRO  system  allows  an  evaluation  of  the  PRO  architecture.  This 
evaluation  was  presented  to  us  during  the  review  and  basically 
the  results  are  that  the  PRO  distributed  architecture  succeeds 
very  well  in  off  loading  the  central  processor.  In  fact,  a 
considerable  number  of  terminals  can  be  supported  with  absolutely 
negligible  loading  of  the  central  processor.  However,  while 
from  a  performance  point  of  view,  the  PRO  architecture  has  proved 
out  to  be  very  effective  there  are  serious  misgivings  with 
regard  to  its  availability. 

During  the  presentation  there  was  considerable  discussion  on 
whether  the  availability  problem  arises  from  the  Host,  or 
the  FEP ,  or  the  remote  terminal  processor,  or  the  lines. 

As  a  result  of  the  discussions  we  requested  that  some 
actual  data  be  given  to  us  with  regard  to  scheduled  time, 
available  time,  and  down  time  for  the  three  classes  of 
processors  namely  Host,  FEP,  RTPC. 

The  data  covers  the  four  weeks  of  November  13,  November  20, 
November  27,  and  December  4,  and  they  are  presented  in  Table  6-1. 


C.  S  I  nr. 
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The  data  is  extremely  significant  and  again  illustrates  that 
a  little  bit  of  data  can  cut  through  endless  hours  of  discussion. 
In  fact,  the  data  shows  that  the  host  was  available  during 
those  four  weeks  for  an  average  of  69.3%  of  scheduled  time,  the 
FEP  was  available  during  the  same  period  for  an  average  of 
98.3%  of  scheduled  time,  and  the  RTPC  was  available  over  the 
same  period  for  an  average  of  96.3%  of  scheduled  time.  From 
these  figures  it  can  be  readily  concluded  that  the  lack  of 
availability  of  PRO  to  the  user  is  largely  determined, 
if  not  exclusively  determined,  by  the  fact  that  the  Host  is 
down  something  like  30.6%  of  scheduled  time .  Therefore,  the 
availability  of  PRO  is  not  the  consequence  of  its  architecture. 

Our  recommendation  is  thus  to  carry  an  in-depth  study  of  the 
causes  of  such  an  excessive  down  time  for  the  Host.  We  also 
recommend  that  a  management  objective  of  gradually  reducing 
the  Host  down  time  be  set  up.  In  addition,  consideration 
should  be  given  to  increasing  the  amount  of  scheduled  time  so 
that  overall  user  availability  can  be  improved. 

A  final  architectural  issue  is  what  should  be  the  implementation 
language  for  the  future  of  AIS.  During  the  presentations  of 
the  CORE  systems  program  the  issue  of  implementation  was 
raised,  namely  the  desirability  to  have  high  level  language 
alternatives  to  the  use  of  assembly  language  (ALC) . 
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Our  recommendation  in  this  area  would  be  that,  provided  that 
the  speed  of  compilation  is  not  extremely  crucial,  and  that 
on  the  other  hand  efficient  object  code  is  an  important  issue, 

AIS  establish  contact  with  various  research  groups  in  the  country 
who  are  experienced  with  PASCAL  and  PASCAL  transportability 
and  bootstrapping  mechanisms.  We  can  assist  AIS  personnel  in 
establishing  these  contacts. 

The  rationale  for  this  recommendation  is  as  follows: 

a)  We  believe  that  the  DoD-1  (now  called  ADS)  initiative 
will  succeed  (over  a  number  of  years) .  DOD-1  is 
PASCAL  derived ,  consequently  a  move  towards  PASCAL 
would  be  a  staging  move  for  an  eventual  adoption  of 
DOD-1  by  AIS. 

b)  Programming  languages  of  modern  type  such  as 
PASCAL,  DoD-1  provide  the  tools  for  producing 
software  which  is  not  only  structured  but  is 
also  designed  for  modern  notions  of  portability. 

c)  There  are  already  a  number  of  PASCAL  compilers  which 
are  written  in  PASCAL  therefore  suitable  for 
bootstrapping  the  compiler  onto  one's  own  machine. 
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6 . 2  CORE  Systems  Issues 

The  most  important  issues  for  the  CORE  systems  area  is  that  of 
the  development  strategy  to  be  pursued  in  light  of  the  Brand 
X  procurement.  Assuminq  the  Brand  X  will  proceed  on  the 
present  course  of  a  totally  A-109  procurement,  the 
planning  of  developments  in  the  CORE  system  area  is  both  very 
difficult  and  very  critical  to  the  success  of  the  Brand  X 
operation . 

From  the  review  we  learned  that  an  effort  to  formulate  a 
CORE  system  design  concept  is  presently  underway.  One 
of  the  very  first  questions  is  :  to  what  use  would  such 

a  design  concept  be  put.  The  possible  uses  as  we  see  them 
are  : 

a)  As  a  blueprint  for  internal  development  to  be 
pursued  once  the  Brand  X  machine  is  available. 

b)  As  a  specification  for  the  Brand  X  procurement. 

c)  As  a  means  to  supply  in-depth  technical  evaluation 
material  to  be  used  during  the  Brand  X  proposal 
selection  phase. 

d)  As  a  blue  print  for  development  to  be  performed 
after  Brand  X  is  known  by  either  the  original 
Brand  X  vendo r  or  other  contractors. 


(V.  (!.,  Inc. 
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e)  As  a  blueprint  for  both  staging  activities 

to  be  performed  before  the  Brand  X  selection, 

and  developments  after  the  Brand  X  selection,  by  OP-16 

people  augmented  by  contractors. 

It  seems  to  us  that  alternative  a)  is  largely  to  be  excluded 
because  the  limited  development  resources  are  already  completely 
applied  to  short  term  development  goals.  Alternative  b) 
has  to  be  excluded  because  it  is  contrary  to  the  spirit  and 
the  letter  of  A-109.  Alternative  c) ,  d) ,  and  e)  are  all  of 
significant  interest. 


In  the  case  of  alternative  c)  the  design  concept  for  CORE 

systems  could  be  a  source  of  technical  evaluation  factors 

with  great  power  of  discrimination  and  selectivity.  Since 

there  is  no  question  that  after  Brand  X  has  been  selected 

the  evolution  of  CORE  systems  will  have  to  continue,  it 

follows  that  alternative  d)  will  be  of  interest  in  guiding 

the  further  work  of  the  Brand  X  vendor  and  associated  contractors, 

However,  the  most  interesting  use  of  a  design  concept 

for  CORE  systems  is  really  alternative  e) .  This  alternative 

really  contemplates  staging  activities  that  could  be 

performed  before  the  Brand  X  is  installed. 


S.  (»..  Inr. 
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What  we  are  referring  to  is  that,  while  for  the  application 
systems  the  Brand  X  procurement  concept  will  guarantee  that 
they  will  transition  correctly  to  Brand  X,  nothing  of  the  kind 
is  available  for  CORE  systems. 

Furthermore,  to  insist  that  a  transition  benchmark  be  used 
for  CORE  system  as  well  as  application  systems  could  be 
construed  as  being  contrary  to  predominant  procurement 
doctrine  and  A-109.  The  reason  why  CORE  systems  cannot 
be  incorporated  in  a  transition  benchmark  is  that  it  is  very 
difficult,  if  not  impossible  to  assert  that  CORE  system 
functionality  is  directly  related  to  mission  requirements. 

Since  CORE  systems  cannot  be  incorporated  in  transition 
benchmark,  the  alternative  is  to  stage  the  CORE  systems 
so  that  equivalent  functionality  can  be  guaranteed  after  the 
transition . 

We  recommend  thus  that  the  present  CORE  system  design  concept 
study  be  redirected  in  the  direction  of  formulating  a  set 
of  requirements  and  a  development  plan  for  CORE  systems  to 
aid  the  transition  to  Brand  X.  Such  a  requirement  study 
and  plan  should  define  the  portions  of  CORE  systems  which 
will  be  implemented  by  a  standard  off-the-shelf  vendor  supplied 
software  and  the  portion  of  CORE  systems  which  will  not. 

For  the  portion  that  will  not  be  implemented  through  off-the-shelf 
vendor  supplied  software  the  plan  should  formulate  a 


a.  s.  in,-. 


50 


series  of  staging  development  activities  aimed  at  bringing 
such  portions  of  the  CORE  software  into  a  transportable 
implementation . 

To  clarify  further  what  we  are  talking  about  let  us  look 
at  something  like  MUM.  First  the  determination  should  be 
made  that  the  likelihood  of  having  the  same  functionality 
from  many  of  the  standard  industrial  vendors  is  low  and 
consequently  that  MUM  would  have  to  be  transitioned  to  Brand  X. 
After  having  made  such  a  determination  one  should  examine 
the  present  implementation  of  MUM  and  decide  whether  or  not  it 
is  intrinsically  transportable  to  most  other  vendor  environments. 
If  it  is  not  one  should  schedule  a  reimplementatior. 
of  MUM  in  suitable  language  and  system  conventions  to 
guarantee  its  portability  to  a  Brand  X  environment. 

A  good  example  of  this  policy  of  staging  towards  a  greater 
reliance  on  the  resources  offered  by  the  industry,  is  given 
by  the  potential  policy  with  regard  to  report  writers.  As 
we  understand  it  the  present  policy  is  to  maintain  a  home 
grown  report  writer.  We  believe  that  this  policy  is  not 
very  satisfactory  from  at  least  two  respects.  One  is  that  it 
ties  up  precious  in-house  development  resources,  the  other 
is  that  a  single  report  writer  cannot  really  span  the  wide 
interests  and  priorities  of  multiple  user  communities. 
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The  present  industry  situation  with  regard  to  report  writers 
that  are  capable  of  interfacing  with  the  TOTAL  DBMS  is  that 
there  are  several  with  different  focus  and  optimization. 

For  instance  Easytrieve  is  optimized  for  casual  inquiry, 

Mark  IV  is  optimized  for  formal  reporting,  besides  these  two 
one  should  consider  also  Culprit  and  Socrates. 

We  thus  recommend  that,  in  line  with:  saving  of  internal 
development  resources,  easier  staging  to  Brand  X,  and  satisfying 
in  a  better  way  the  user  communities,  AIS  consider  the  adoption 
of  a  policy  of  having  multiple  report  writers  commonly  marketed 
in  the  industry  and  capable  of  interfacing  with  the  TOTAL 
DBMS . 

Both  during  the  presentations  of  the  CORE  system  program 
and  those  of  the  U&QC  function  the  topic  of  dedicated 
initiators  came  up.  A  scheduling  policy  based  on  the  use  of 
dedicated  initiators,  controlling  partitions  dedicated  to 
particular  users  of  the  AIS  system,  leads  to  potential 
under  utilization  of  the  mainframe  computer  resources.  On 
the  other  hand  such  a  policy  can  be  a  wise  policy  in  the 
initial  phases  of  an  integration  in  so  far  that  it  can  give 
a  guarantee  of  priority  control  to  a  specific  user  community. 
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In  light  of  the  two  above  considerations  we  recommend  that 
AIS  pursue  the  development  of  a  general  purpose  resource 
allocator  for  its  mainframe  facility,  and  that  the  individual 
cases  of  dedicated  initiator  be  reviewed  periodically 
(at  least  once  every  six  months)  at  the  OP-16  staff  level 
to  determine  whether  continuation  of  such  privelege  is  still 
warranted.  These  reviews  should  generate  a  trend  towards 
the  elimination  of  such  special  handling  of  resource  allocation 
over  a  period  of  time.  Thus,  a  more  efficient  utilization 
of  computer  resources  will  result  without  any  traumatic  impact 
on  user  communities. 


S.  c  .  hi.  . 
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b . 3  MIS  Issues 

During  the  presentations  on  SDS  it  became  very  apparent  that 
present  trends  are  that  three  separate  SDS  applications  will 
evolve,  they  are:  the  military,  the  reserve,  the  civilian. 
Although  unification  in  the  source  data  area  is  a  tough 
proposition  and  extreme  unification  is  not  necessarily  a 
desireable  goal,  we  still  believe  that  the  emergence  of 
three  separate  SDS  applications  should  be  under  some  kind 
of  scrutiny. 

We  recommend  thus  that  the  SDS  development  group 
document  the  nature  of  the  discrepancies  between  the  various 
SDS  applications,  namely  difference  in  forms  and  procedures 
and  that  it  attempts  to  isolate  as  many  of  these 
differences  which  are  resolvable  by  negotiation  with  the 
users  as  possible,  and  clearly  document  those  that  because 
of  alleged  heavy  procedural  impact  on  the  user  cannot  be 
so  resolved. 

By  making  this  kind  of  effort  one  would  increase  the  probability 
that  frivolous  and  superficial  differences  between  the  three 
applications  do  not  become  institutionalized  in  the  SDS 
implementation. 

Another  important  is^ue  in  the  MIS  area  is  that,  for 
a  variety  of  reasons,  the  visibility  of  delivered  applications 
to  the  user  community  has  been  and  is  poor.  For  instance, 
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in  this  review  the  following  information  was  presented  to  us: 

a)  TOPS  has  not  been  implemented  in  October  as  per 
plan  and  is  presently  projected  to  be  completed 
in  the  March/June  79  timeframe.  This  delay 

is  primarily  attributed  to  the  need  to  shift 
resources  away  from  TOPS  to  SDS  and  also  to 
hardware  problems. 

b)  NMDAS  (formerly  BFM)  is  now  projecting  completion 
in  the  Fall  of  79.  This  is  primarily  due  to  hardware 
unavailability  and  the  impact  of  integrating  civilian 
positions  into  the  BFM  module  and  to  staffing  problems. 

Given  the  work  still  to  be  done  we  are  somewhat  skeptical 
that  the  Fall  79  deadline  will  be  achieved. 

c)  The  officer  order  writing  system  sees  the 
development  stretched  out  over  three  phases 

with  respective  dates  of  August  1980,  August  1931, 

August  1982.  We  were  told  that  this  timing  is 
driven  by  the  user,  namely,  the  OP-13  staff 
ability  to  accept  the  product. 

All  three  of  the  above  share  one  common  characteristic,  namely 
that  the  development  time  to  complete  an  application  is 
excessively  lonq .  This  is  certainly  true  of  officer  order  writing 
which  is  planned  For  a  span  of  over  three  years  and  ofNMPAS 
which  was  under  development  three  years  ago  when  we  f.rst  reviewed 
the  then  future  MAPMTS  project. 

<,  \  i.  .  /v  . 
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..'i'-  The  extremely  long  development  times  for  the 

;  d.  MIS  applications  is  contrasted  on  the  other  hand  by  fairly 

rapid  advances  in  the  CORE  system  area,  at  least  in  the  last 
three  years.  This  in  turn  is  an  indicator  that  the  priorities 
are  probably  somewhat  off-balance, since  ultimately  the  best 
system  software  will  get  absolutely  no  credit  unless 
applications  which  are  truly  visible  to  the  users  come  into 
being  and  fully  utilize  the  capabilities  of  the  system  softwa 
Part  of  this  delay,  we  understand  from  our  previous  reviews, 
was  caused  by  the  suspension  of  applications  development 
pending  the  formulation  of  a  MAN' T PAPERS  plan  and  retamping 
of  the  AIS  development  plan  from  the  old  future  MAP MIS  plan. 
But  even  making  allowance  for  these  management  redirections 
we  believe  there  are  still  fundamental  problems  with  regard 
to  the  way  applications  are  being  undertaken  within  AIS. 

We  would  recommend  that  a  policy  be  adopted  that  any  aoplicati 
subsystem  that  is  committed  within  the  AIS  framework  de¬ 
limited  to  have  a  first  release,  utilizable  in  true  opcrativn.il 
conditions,  withing  18  months  of  start  of  the  project.  Insists 
in  such  a  policy  is  healthy  for  two  reasons.  Firs’",  ^  wools 
guarantee  that  users  see  some  concrete  results  within  a  reason 
time,  secondly,  it  would  force  to  head  those  situations  where 
either  the  CORE  system  foundation  is  not  adequate  to  support, 
the  proposed  application  or  the  concept ca’  formulation  of  the 
application ,  both  in  terms  of  its  functionality  and  architect'.! 
is  basically  unsound  or  overly  complex. 


i.  '  <•  / 
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What  we  are  suggesting  is  a  policy  whereby  MIS  applications 
would  have  either  a  first  concrete  deliverable  release  to  user 
within  24  months  of  the  start  of  the  project  (or  alternatively 
18  months  from  the  date  of  completion  of  functional  requirements) , 
or  obtain  a  waiver,  but  this  waiver  would  result  only  upon 
an  in-depth  review  by  both  the  System  Architect  and  the  P&P 
function  with  the  waiver  of  course  being  released  by  OP-16. 

Another  benefit  of  this  policy  is  that  it  would  force  a 
clarification  of  the  perspective  of  the  functional  scope  of 
an  application  system, such  as  NMDAS,  and  its  implementation 
plan.  Namely,  the  implementation  plan  could  be  formulated 
in  terms  of  incremental  implementations,  the  first  of  which 
would  occur  24  months  after  the  start  or  sooner.  Subsequent 
implementations  would  then  eventually  drive  towards  the 
full  implementation  of  the  functional  scope  of  the  subsystem. 

A  final  important  point  we  wish  to  make  with  regard  to  the  MIS 
activities  is  that  this  development  group  has  a  very  key  role 
in  the  success  of  the  Brand  X  procurement.  The  point  being 
that  the  chief  components  of  the  conversion  benchmark  are 
subsystems  which  are  developed  and  maintained  by  MIS.  It 
appears  to  us  therefore  that  it  is  imperative  that  suitable 
participation  of  the  MIS  group  into  the  Brand  X  activities  is 
secured.  This  participation  can  be  expected  to  be  of  a 
substantial  level  since, if  our  previous  experience  in  similar 
conversions  is  a  guide,  it  will  be  necessary  to  do  a  considerable 
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amount  of  work  in  documenting  or  improving  the  documentation 
of  the  elements  of  the  conversion  benchmark.  What  we  are 
referring  to  is  that  it  will  be  necessary  to  generate  a 
transition  or  conversion  library  for  the  vendors  to  use. 

This  generation  of  the  transition  library  can  only  be 
performed  by  substantial  participation  of  MIS  personnel 
(whether  contractors  are  used  or  not) . 


G.  S,  C.,  Inc, 
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6.4  Miscellaneous 

We  believe  that,  as  we  stated  above,  an  important  evolution 
of  the  AIS  development  group  is  to  move  more  and  more  in  the 
direction  of  using  an  increasing  share  of  contractor  assist 
and  therefore  shifting  away  from  direct  development  to  more 
of  a  mode  of  contract  formulation  and  contract  monitoring. 

If  this  belief  of  ours  is  correct,  then  the  present  organizational 
know-how  needs  additional  strengthening.  We  would  recommend 
the  following: 

a)  Take  deliberate  steps  to  get  more  personnel 
trained  to  properly  control  and  monitor  the 
activities  of  contractors.  At  present  we 
know  of  only  very  few  individuals  which  are 
fully  qualified  to  monitor  contracts. 

b)  Shift  towards  a  mode  of  increasingly  contracting 
for  a  definite  product  or  service  as  opposed 
to  contracting  for  bodies. 

c)  The  present  priorities  are  to  contract  out 
the  parts  of  the  system  which  are  further  away 
from  the  hardware.  This  is  precisely  the 
opposite  from  the  general  industry  trend  where 
subcontracting  or  vendor  supplied  off-the-shelf 
components  are  usually  in  the  inner  layers  of 
the  system,  while  the  further  out  a  component 

is,  the  more  likely  it  is  to  be  implemented  in-house. 
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The  reason  why  the  outer  layers  of  the  system  should  be 
done  in-house  is  that  the  further  out  components 
of  the  system  are  they  are  the  ones  more  intimately 
linked  to  mission  specific  knowledge. 

While  the  inner  layers,  being  technically 
more  challenging ,  are  the  ones  that 
tend  to  be  universally  valid  for  various  groups 
and  applications. 

A  final  and  seemingly  minor  point  is  that  the  present  version 
of  the  strategic  plan  uses  the  term  goal  as  synonomous  of  a 
development  process.  The  orginal  AIS  plan  had  Goal  1,  II,  and  III 
which  were  respectively  defined  as  follows:  Goal  I  was  the 
consolidation  of  the  computer  facilities  in  a  single  location: 

Goal  II  was  the  implementation  of  SDS;  Goal  III  was  the 
installation  and  operation  of  Brand  X. 

In  other  words  the  original  definitions  of  Goal  I,  II,  and  III 
was  in  terms  of  a  tangible  accomplishment  that  could  be  clearly 
measured  and  observed  and  therefore  goals  could  be  achieved. 

The  present  strategic  plan  is  talking  in  terms  of  goals  which 
are  the  process  of  continuing  the  evoluation  and  maintenance 
of  the  consolidated  facility,  the  process  of  continued  enhancement 
and  evolution  of  SDS,  etc. 
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The  reason  why  this  use  of  the  term  goal  is  poor  is  that,  from 
a  point  of  view  of  senior  management,  a  goal  is  something 
that  has  to  be  accomplished  at  some  definite  point  of  time 
and  it  would  be  very  harmful  to  the  project  to  inadvertently 
convey  the  impression  that  goals  are  never  achieved.  While 
of  course,  it  is  very  true  that  ADP  development  processes 
are  never  truly  terminated.  Thus,  we  recommend  that  the 
strategic  plan  in  the  next  version  be  rewritten  substituting 
the  word  goal  with  either  product  or  service,  in  other  words, 
we  would  be  talking  about  the  consolidated  services  rather  than 
Goal  I,  the  SDS  product  rather  than  Goal  II,  etc. 
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7.0  User  Interface 

In  all  of  our  previous  reviews  we  have  never  really  had  an 
opportunity  to  look  probingly  into  the  interface  between  the 
AIS  organization  and  its  user  communities.  For  instance,  we 
can  think  of  a  number  of  key  questions  that  AIS  management 
should  repeatedly  pose  and  answer  and  to  which  we  can  give 
either  no  answer  or  a  partial  answer.  Some  of  the  most 
important  questions  are: 

Is  the  user  getting  more  in  1978  than  he  was 
in  1975?  What  can  he  expect  in  1981? 

-  Is  there  a  committed  user  for  data  processing 
systems? 

-  Is  the  user  more  or  less  help  to  data  processing? 

-  Has  DP  taken  the  time  and  effort  to  educate  the 
user? 

Since  in  all  of  the  previous  reviews  of  AIS  we  have  rarely  seen 
bonafide  users ,  the  following  recommendation  would  improve 
our  insight  on  how  effective  AIS  is  with  respect  to  users. 

We  recommend  that  in  future  reviews  a  representative  for  each 
of  the  OP-1X,  whichare using  communities  of  the  OP-16  products 
and  services,  attend  the  reviews  and  brief  the  GSG  team  on  a 
specific  recent  user  acceptance  experience  with  an  OP-16 
product  or  service. 
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On  the  very  important  issue  of  how  application  priorities  are 
established ,  AIS  has  set  up  a  consumer  board  which  is  chaired 
by  0P-1X  with  the  membership  being  the  deputy  in  all  of  the 
OP-xx  organizations  other  than  OP-16.  We  understand  that  the 
consumer  board  does  a  preliminary  stage  of  priority  setting. 

We  do  not  have  information  on  the  followup  for  this 
priority  setting,  and  consequently  how  final  priorities  get 
established. 

We  believe  that  the  key  representation  (represented  by  the 
deputy)  of  the  functional  managers  on  the  consumer  board  is 
absolutely  essential  for  guaranteeing  its  credibility  and 
priority  setting.  We  also  believe  that  in  order  for  the  board 
to  be  effective  suitable  staff  work  be  available  to  it  so  that 
thorny  priority  issues  can  be  staffed  and  researched  in  pre¬ 
paration  of  the  board  achieving  resolution.  The  other 
key  factor,  in  making  such  a  board  a  valuable  mechanism,  is  to 
make  sure  that  it  does  not  just  do  the  preliminary  priority 
setting  but  that  it  has  the  ability  to  re-examine  these 
priorities  at  periodic  intervals,  say  every  6  months.  First  to 
verify  that  they  are  being  reflected  by  the  implementation 
plans  of  OP-16  and  it  has  an  opportunity  to  incrementally 
change  them  if  the  OP-01  environment  so  requires. 
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In  addition  to  the  above  long  term  problems,  we  are  particularly 
concerned  about  a  special  short  term  problem.  The  problem  is 
that  with  the  recent  reorganization  of  the  Bureau,  functions 
which  have  been  for  many  years  separated,  are  formally  unified, 
like  for  instance  officer  and  enlisted  men  distribution.  It 
would  be  very  dangerous  for  OP-16  and  AIS  management  to  completely 
trust  this  functional  reorganization  to  yield  truly  unified 
requirements.  To  avoid  this  very  subtle  danger  we  recommend 
the  following: 

-  OP-13,  military  personnel,  is  to  set  up  a  mechanism 
for  unified  guidance  to  OP-16. 

-  P&P/PM  to  pay  extra  care  on  all  of  those  user 
requirements  and  product  packaging/delivery 
commitments  which  are  made  on  behalf  of  users  which 
have  undergone  a  drastic  reorganization  within  the 
recent  reorganization  of  the  Bureau. 


(J.  S.  G.,  Inc. 


